微服务架构和容器技术应用_软件应用

微服务架构是一种架构风格和设计模式，它提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制相互沟通、配合来实现完整的应用，满足业务和用户的需求。

微服务架构的诞生，是云计算技术应用以及持续交付、DevOPS深入人心的综合产物，它是未来软件架构朝着灵活动态伸缩和分布式架构发展的一个方向。同时，以Docker为代表的容器虚拟化技术的盛行，将大大降低微服务实施的成本，为微服务落地以及大规模使用提供了基础和保障。

微服务架构的特性

　　微服务架构(Micro Services Architecture，MSA)是一种架构风格和设计模式，它提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制(如HTTP／REST)相互沟通、配合来实现完整的应用，满足业务和用户的需求。

　　从上述概念中，可以看到微服务的一些特点：专注于实现有限的业务功能；独立于其他(微)服务，或者在某些情况下，很少依赖其他服务，实现服务之间的解耦；通过不依赖语言的API进行沟通；与底层平台和基础设施解耦。

　　1．微服务架构的优势。微服务的目的是有效拆分应用，实现敏捷开发和部署。在微服务架构下，我们将原本单一的应用按照业务功能边界分解成一系列独立、专注的微服务。每个微服务对应传统应用中的一个组件，但是可以独立编译、部署和扩展。相对传统架构的应用，微服务具备以下优势。

　　★低复杂度：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。可由小规模开发团队进行开发，从而提高开发效率并易于维护。

　　★技术灵活：每个开发团队可以根据自身特点自由选择最适合的技术。另外，后续功能的变更等很容易掌握，无需被原厂商捆绑。

　　★独立部署：具备独立的运行进程，所以可以独立部署。当某个微服务发生变更时一般仅影响自己，无需像传统应用那样编译整个应用。因此微服务较容易实现灰度发布，在加快发布频率的同时，降低对生产环境造成的风险。

　　★易扩展：每个微服务可以根据实际需求独立进行灵活扩展，且资源更节俭。

　　★容错性好：在微服务架构下，故障会被隔离在每个微服务中，不会导致整个应用不可用。

　　★重用性好：因微服务的功能较为独立，更利于被重用。

　　2．微服务架构的缺点。微服务架构可能带来过多的操作；因为分布部署跟踪问题难；随着微服务数量不断增加，其管理复杂性也将增加；微服务应用是分布式系统，会带来固有的复杂性；微服务之间会有依赖关系，因此部分微服务的功能调整也会波及其他相关服务；微服务是分布式架构，相应的数据库如能实现分布式架构，则将大大提高其可用性，而分布式数据库将受到CAP理论的限制，目前的解决方案不多。

　　3．微服务架构与ESB架构的关系。SOA架构以前一般与ESB结合在一起，可以认为是一种以ESB为中心的架构，通过ESB实现应用之间服务的调用。而微服务架构可以看成是另外一种实现SOA的架构，微服务架构模式是一个不包含Web服务(WS一)和ES B服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，它是一种去中心化的架构，不采用ESB架构。

利用容器技术实现微服务

　　容器技术是实现微服务很好的选择。将应用(微服务)以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器完全使用沙箱机制，不依赖于任何语言、框架包括系统。基于容器的应用(微服务)封装与经过优化的强大基础架构相结合，使经认证的应用能够在裸机系统、虚拟机和私有／公共云之间轻松移动。

　　容器技术和虚拟机的功能有些相似，但性能相差很大。与虚拟机相比，容器技术通常可以在1秒内启动，而虚拟机启动加上应用系统的启动时间要长得多；且资源利用率高，一台普通X86服务器可以跑上千个容器，而虚拟机能跑几十个已经非常好了；另外，性能开销小，虚拟机通常需要额外的CPU和内存来完成OS的功能，这一部分占据了额外资源。

测试情况分析

　　利用容器技术来封装微服务，能弥补微服务的不足，两者相辅相成。下面是我行互联网应用的测试情况。本次测试的应用系统简单分为4个微服务，数据库仍使用传统的DB2数据库。

　　★IB—Rest：接收HTTP请求报文，等互联网核心后台对交易处理好后，返回HTTP响应报文。

　　★IIB—Gateway：记报文流水，并路由到相应的交易。

　　★IIB—Service：联机处理模块，用于联机交易的后台处理，如进行开户、消费、退货等交易。

　　★I Rabbit MQ：消息队列，用于上述3个模块之间的通讯。

　　我们采用了开源的PaaS产品CIoud Foundry，利用其自带的Gartner容器，对上述微服务进行封装。

　　1．测试环境。下述两种架构的数据库采用DB2数据库，独立部署在物理机上，其应用部署如图1所示。

图片1.jpg
图1 传统应用和微服务架构部署环境

　　★传统应用架构部署环境：该应用系统在测试环境的部署情况是Rest、Gatway和Service、Rabbit MQ等4个模块均同时部署在4台虚机上，每个虚机4Core／16GB。

　　★微服务架构部署环境：除了Cloud Foundry产品占用的资源外，该互联网应用的4个微服务部署在2个虚机上，每个虚机配置为2Core／8GB。为了实现负载均衡，另外有一个软负载均衡服务HAProxy，部署在一个虚机上，配置为2Core／8GB。

　　2．测试内容和结果。传统架构和微服务架构所占资源(不包括数据库)、性能测试情况分别如表1和表2所示。在应用重启上，传统架构IB—Rest为6.5秒，IB—Gateway是8秒，IB—Serivce是7.5秒，如果虚拟机一起重启，则时间会更长；启动5～10个容器，可在1～5秒钟内完成。在资源动态伸缩上，可以通过参数配置(CPU利用率)，实现容器弹性伸缩。通过测试发现，在1500并发下，IB—Rest性能压力不大，始终1个容器；IB—Gateway压力较大，自动扩展至4～5个容器；IB—Serivce压力一般，需2个容器。

图片2.jpg