谈谈微服务架构

Posted 2021-04-14 国家电投集团信息技术有限公司

传统应用架构的弊端最早在大型企业和互联网行业中呈现，这些公司都遇到了复杂应用的开发维护成本变高、代码重复率增大、团队协作效率变差、系统可靠性变低、系统水平扩展困难、新功能上线周期变长等问题。因此众多大型公司经过了反复实践和尝试，推出了各种轻量级的架构模式，有效的解决了上述问题，微服务架构的概念也就应运而生。本文谈一下微服务的来龙去脉和应用方式。

传统信息化建设面临的挑战

随着信息化建设的深入，业务应用的快速变化和高效创新已经成为所有公司信息化发展的新常态。这期间业务系统架构大多采用的是传统分层应用架构模式，这种模式的优点是层次分明、开发简单、组件共享和测试相对容易、应用部署比较简单等。但上述优势在信息化发展的新形势下将面临着许多新挑战：

1）应用灵活性差。传统的企业应用架构模式下，对应用程序做任何细微的修改都需要将整个应用程序重新构建和部署。多个研发人员共同开发一个业务系统，需要全部研发人员都完工后才能做交付。系统变庞大后代码难以修改，被修改的程序可能会以意料之外的方式被其他模块调用，随着时间推移和人员更迭，这必然会增加应用程序的技术债务，降低应用的灵活性和交付频率。

2）系统扩展困难。随着业务规模的不断增长，业务系统需要满足高并发请求以及海量数据交互的要求。传统的企业应用架构模式下，大多通过垂直方式复制应用程序与数据，以解决容量和性能问题，当出现性能瓶颈时基本通过升级硬件方式解决，操作成本较高。

3）持续交付面临巨大挑战。传统应用架构模式下，业务模块之间的循环依赖、重复定义、冗长复杂的业务流程等问题对新特性的上线造成极大阻力。而且传统业务应用的“体量”比较大，构建、部署和启动时间比较长，配置也较复杂，在研发环境中的效果与运行环境中的效果很难统一，不利于快速上线频繁部署，阻碍了持续交付。

4）运维难度大。传统架构的应用在运维阶段，某功能组件出现无法恢复的故障时，整个节点处于不可用状态。此时业务应用的功能越丰富，影响面则越大，即使一个小问题都会导致极大影响；同时在定位问题时，由于功能组件过多，不易迅速进行定位和识别。

以上这些挑战会为企业信息化建设带来如下问题

l 不同业务系统间的连接和集成成本非常高，影响部门协同；

l 已有的系统会越来越庞大，升级与维护越来越困难；

l 新建系统无法有效的复用之前的软件资产，浪费企业资源；

l 重复建设的情况会越来越多，严重的影响应用系统的交付进度和质量，制约业务发展；

这些问题会让企业的信息化建设呈现出信息孤岛的状态。

企业的各个信息化系统如同孤岛一般存在

微服务架构

为了应对上述挑战，业界众多大型公司经过了反复实践和尝试，并结合了互联网、敏捷开发、虚拟化、持续交付及开发运维一体化等要求和特点，推出了各自轻量级的架构模式，有效的解决了传统应用架构所引发的问题，这些轻量级的架构模式都具备以下特点：

1）体量小、易于开发和维护、能够独立运行和部署。一个大型的企业应用系统按业务领域可以被分解为多个可管理的小应用，每个小应用都有清晰的系统边界，因此单个的小应用要更容易开发、理解和维护。业务逻辑不再集中在几个大型模块中，而是由大量相对小的领域对象组成，每个领域对象具备自己的状态和行为，是相对完整的独立体，并与现实中业务领域对象形成映射关系，保证了系统的可维护性、扩展性和复用性，在处理复杂业务逻辑方面有着先天优势。

2）易于水平扩展。在分布式环境中，每个应用都携带着整个分布式环境的节点信息，当A应用调用B应用时，A应用会根据节点信息按照负载均衡策略计算出调用哪一个B应用。当环境中新增或删除一个应用节点时，会将相关信息自动同步到分布式环境的所有节点中，应用间的调用都应采用轻量级的通信模式，减轻对网路资源的消耗。

3）持续集成和快速交付。在业务需求快速发展的模式下，需要应用系统具备可持续集成和快速交付的能力，在研发过程中开发人员不需要费时协调其他应用对自己应用的影响，为持续集成和快速交付提供基础性技术支撑。

4）运维更便捷。每个业务应用都内嵌运行容器，以完全独立的方式部署和运行，应用配置更加简单。在业务应用运行过程中无论是单独部署、重新部署或升级都不会影响整个系统的运行，系统出现问题时能更快速的定位。

通过对以上特点的梳理和抽象，Martin Fowler于2014年提出了微服务架构的概念，总的来说该架构旨在通过将系统的功能分解到各个离散的应用中以实现对解决方案的解耦。微服务一般按照业务功能来拆分，关联性较强的业务对应一个微服务，每个微服务都是可独立部署的，微服务之间有明确的边界，可独立扩展伸缩。一个微服务包含自服务容器和运行于自服务容器中的业务应用。一般情况下微服务按照业务领域来拆分，将关联性较强的业务功能进行聚合，并把应用的重用性、灵活性和性能等要求等作为确定应用粒度大小的重要参考指标，因此在不同的业务领域或场景中每个微服务的大小是不尽相同的。微服务的主要特征如下：

1）原子服务。专注于做“一件事”。功能越单一对其他功能的依赖就越少，内聚性就越强，符合“高内聚，松耦合”的标准。

2）应用自治。应用足够小，功能单一，可以独立打包、部署、升级、回滚和弹性伸缩，不依赖于其他微服务，实现局部自治。

3）敏捷交付。每个微服务都可以由较小规模的研发团队负责设计、开发、测试、部署、运行治理及灰度发布等，是实现开发运维一体化（DevOps）的基础。

4）灵活部署。微服务可以独立部署，即可以将多个相同的微服务部署到不同的服务器上，也可以在一台服务器上部署多个微服务实例，具备高可靠的水平扩展能力。如果是云端部署则可以利用轻量级的虚拟机容器进行部署，有效的降低部署成本，提高资源利用率。

微服务架构

基于微服务架构的应用和传统架构应用系统相比呈现出功能少、体量轻、能够快速交付和敏捷响应需求变更的特征，特别适用于云应用、互联网应用以及基于单个分析主题的智能决策型应用。像ERP这样的已有的大型管理应用，也可以逐步进行解耦，逐渐向微服务模式演进。

微服务的开发

微服务的开发首先要考虑的是业务系统如何组件化和模块化，一个完整的业务系统根据松耦合的原则通过业务建模和架构分析被拆分为多个业务组件，业务组件最终转换为业务系统中的应用模块，每一个模块就是一个微服务，可以独立进行设计、开发、测试、部署和后续运维的管理。

 微服务划分的粒度应该按内聚的功能需求进行分析，这是微服务之间能够松耦合的基础。微服务之间的交互或者微服务向外暴露的功能是以服务接口的方式提供的，微服务需要满足粗粒度服务的基本特征，即服务的消费方完全不需要了解微服务内部的实现逻辑和细节，而只需要根据业务场景调用微服务对外的接口。需要注意的是微服务对外公开的服务接口是领域模型的服务功能，而不是数据库级别的增删改查接口。如果微服务所公开的服务是纯数据访问层的服务，将完全违背领域驱动原则。

对于每个微服务而言，由于其本身模块化比较清晰，因此在一开始，最重要的事情不是立刻实现功能上的开发，而是优先考虑如何在交付的过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署行。有了这个过程，研发团队就能够频繁有序地实现业务逻辑，并进行快速迭代，从而驾驭微服务的快速交付。在微服务开发过程中，与其他系统的集成也是一项重要的工作，特别是与权限与流程系统的集成，是所有业务应用必不可少的。

微服务的部署

部署微服务有两种方式：单主机多应用实例模式和单主机单应用实例模式。对于单主机多应用实例模式，每台机器上运行多个微服务实例，这是传统的应用部署方法。如下图所示。

单主机多应用实例模式

单主机多服务实例模式主要优点如下：

l 多服务实例共享服务器和操作系统，如果进程组运行多个服务实例效率会更高。

l 另一个优点在于部署服务实例较快，因为微服务都是自包含的独立体，只需将微服务部署包拷贝到主机直接启动即可。

除了上述优点外，单主机多微服务实例也存在缺点：

l 因为没有限制每个微服务对资源的使用，因此有可能造成某个设计不良的微服务实例占用了主机的所有内存及CPU，或者直接引起的操作系统的宕机，从而容威胁到同一服务器中的其他微服务。

l 另一个问题是如果运维团队和研发团队分立情况下，运维人员必须知道部署的详细步骤，如果一台服务器部署了特别多的微服务，开发团队会有很多需要跟运维团队沟通事项，增加了部署过程中沟通的成本。

另外一种部署微服务方式是单主机单实例模式。当使用这种模式，每个主机上应用实例都是各自独立的，如下图所示。

单主机单实例模式

单主机单实例模式有许多优势，主要的优势在于每个微服务实例都是完全独立运行的，都有各自独立的CPU和内存而不会被其它微服务占用。单主机单实例也有缺点。一个明显的缺点就是资源利用效率不高，每个微服务实例占用整个服务器的资源。而且在一个IaaS环境中，虚机资源都是标准化的，会造成资源没有被充分利用。

传统应用架构向微服务架构演进的策略

微服务开发框架支持快速构建“微服务”，在带来质的飞跃同时，也对兼容性提出了巨大挑战。因此建议将传统应用改造为微服务的过程不应该重新开发来实现，而是循序渐进地改造传统应用成为一系列微服务。以下三种策略可以考虑：

1）用微服务实现新的功能。

当传统应用已经变得难于管理的时候，不适于在原有的基础上继续扩建。如果有新的功能特性需要添加，不要在传统应用中添加代码，而要把新的代码放在另一个单独的微服务中。

2）将表现层组件从业务逻辑和数据访问层组件中分离出来。

缩减传统应用的一个策略是将表现层从业务逻辑和数据访问层中分离出来，一个典型的传统应用一般包括三层，即：表现层、业务逻辑层和数据访问层。在表现层逻辑与业务和数据访问逻辑之间通常有着明显的区分，业务逻辑层有一个粗粒度的接口供表现层调用，所以可以分割为更小的微服务。一个微服务包含了表现层，另一个微服务包含了业务和数据访问层，表现层微服务可以远程调用业务逻辑层微服务。这样分割传统应用有两个主要好处，首先可以独立地开发、部署和扩展两个应用，对于表现层开发者来说，他们可以实现用户界面的快速迭代；其次这样做会向外开放一个可以调用的远程接口，能为更多系统提供服务。但是这个策略只解决了部分问题，拆分出来的两个微服务很有可能变成两个混乱的单体应用，这就需要用下面的策略去减少单体部分的比重。

3）改造传统应用中的模块为微服务。

这个策略的目的是将传统应用中的模块，转变为单独的微服务。每次提取一个模块，改造为微服务，传统应用就缩减了。一旦转化了足够的模块，最后不管传统应用是完全消失还是变成了另一个微服务，都不是问题了。

一个大型的复杂传统应用，通常包含数十甚至上百个模块，都可以被提取出来，选择先提取哪个模块是个复杂问题。可以从容易被提取的模块开始，积累微服务的经验，然后提取那些能给业务系统带来最大好处的模块，通常是那些频繁变化的模块，一旦将这样的模块提取出来，就可以独立开发和部署了。另外一个就是提取那些资源需求和其它部分有很大不同的模块，例如将一个和内存数据库关联密切的业务模块转变为微服务，可以把它部署在一个内存很大的主机上；同样思路，提取那些实现复杂算法的业务模块转变为微服务，可以把它部署在CPU多的主机上，这样做有助于扩展应用。当决定了提取哪个模块后，需要分析现有的粗粒度边界，可以帮助将模块转化为微服务，例如一个只有通过异步信息和其它应用交互的业务模块，就很容易能被改造成微服务。

结束语

微服务架构即可以有效的解决随着业务系统不断扩展而产生的信息孤岛问题，又能够处理企业的信息系统数据量的高速增长与数据处理能力的相对不足，有效的配合IaaS和PaaS平衡计算资源的利用率。在关键技术方面，微服务架构可以实现业务组件的可重用性、敏捷性、松耦合，并能有效的水平扩展；在应用场景方面，微服务架构既能满足企业的业务需求的快速变化，又能满足应用系统大量批处理计算的需要；在应用的侧重点方面，微服务架构既侧重于采用应用服务化的模式进行系统的设计以关注如何构建服务，又侧重于服务的提供和使用以关注如何提供服务；在经济效益方面，微服务架构既可以有效的降低软件开发及维护的成本，又能适需要根据微服务的使用时间或流量进行计费。相信随着云时代的到来，微服务架构将成为企业信息化建设的最主流的架构模式。