微服务架构

微服务的历史背景     

      微服务架构的产生和流行并不是偶然的，它是多重因素推动下的必然结果，下面通过对传统MVC垂直架构面临的挑战进行相关分析，来了解微服务化所带来的变化。

研发和运维成本高

1、代码重复率高

1）从技术架构角度看，传统垂直架构的特点是本地API接口调用，不存在业务的拆分和互相调用，使用到上面功能就本地开发，不需要过度依赖于其他的功能模块。

2）从考核角度看，共享很难推行。开发只需要对自己开发的模块交付质量负责，没有义务为他人提供并维护公共类库，这个非常耗费成本。

3）时间依赖很难把控。对于公共类库的使用者而言，依赖别人提供此功能，但是功能提供者可能有更重要的事情在做，交付时间无法满足使用者。与其坐等别人提供，还不如自己开发效率更高。

4）跨地域、跨开发小组协调很困难，业务团队可能跨地域研发，内部通常也会分成多个开发小组，各个开发小组之间的协调和沟通成本非常高。

    功能的重复开发会导致研发成本的上升，代码质量的下降，架构腐蚀，为后续系统的运维和新功能的开发带来了巨大的挑战。

 

2、需求变更困难  

      代码重复率变高之后，已有功能变更或者新需求加入都会非常困难，以充值缴费功能为例，不同的充值渠道开发了相同的限额保护功能，当限额保护功能发生变更之后，所有重复开发的限额保护功能都需要重新修改和测试，很容易出现修改不一致或者被遗漏，导致部分渠道充值功能正常，部分存在Bug的问题，如下图所示：

 

 

 

   修改不一致导致的移动APP充值失败示例，如下图所示

 

 

图--充值限额保护功能需求变更后

3、代码维护困难

    

   在传统的MVC架构中，业务流程是由一长串本地接口或者方法调用串联起来的。臃肿而冗长，而且往往由一个人负责开发和维护，随着业务的发展和需求变化，本地代码再不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原理的开发者才能理解接口调用的关系和功能需求，一旦原有的开发者离职或者调到其他项目组，这些功能模块的运维就变得非常困难，如下图所示：

 

 

 

图--垂直架构导致的功能孤岛

4、部署效率低

  

      部署效率低主要体现在一下三个方面：

1） 业务没有拆分，很多功能模块都能打到同一个war包中，一旦有一个功能发生变更，就需要重新打包和部署。

2）巨无霸应用由于包含功能模块过多，编译、打包时间比较长，一旦编译过程出错，需要根据错误重新修改代码再编译，耗时较长。

3)  测试工作量较大，因为存在大量重复的功能类库，需要针对所有调用方法进行测试，测试工作量大，另外，由于业务混在一起打包，需要针对集成打包进行专项测试，客观上也增加了测试工作量。

微服务带来的变化

     

      采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是，单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能，如果 A 功能发生变化时同时 B 功能也需要变化，那么 A 和 B 这两个功能应该被划在一个服务中。

      微服务架构应用的成功经验近年已越来越多，例如国外的 Amazon，Netflix，国内如阿里都采用微服务架构取得了很多正面的成功案例。 但通过上文所述微服务架构特征看出，其实微服务架构模式有利有弊，需要根据实际的业务、团队、环境进行仔细权衡利弊。 其中的服务拆分带来的额外开发、测试、运维、监控的复杂度，在现有的环境、团队下是否能够很好的支持。

     另外，有人可能会说，我一开始不采用微服务架构方式，而是在单一进程内基于清晰定义的模块化方式，模块之间通过接口调用，到了适当阶段，必要的时候再将模块拆分为服务。 其实这个想法显得过于理想，因为进程内良好定义的接口通常不是很好的服务化接口。 一开始没有考虑服务化的设计方法，那么后期拆分时依然是一个痛苦的过程。

 

应用解耦

      微服务化之前，一个大型应用系统通常会包含多个子应用，不同应用主键存在很多重复的公共代码，所有应用公用一套数据库，它的架构如下图所示：

 

 

                           图--传统应用架构

    

   将服务A和B服务化之后，应用作为消费者直接调用服务A和服务B，这样就实现了对原有重复代码的收编，同时系统之间的调用关系也更加清晰，如下图所示：

 

 

 

图--服务化之后的调用关系

 

      基于服务注册中心的订阅发布机制，可以实现服务消费者和提供者之间的解耦，消费者不需要配置服务提供者的地址信息，即可以实现位置无关的透明化路由，它的开发体验与本地API接口调用相似，但是却实现了远程服务调用。通过服务注册中心，可以管理服务的订阅和发布关系，查看服务提供者和服务消费者的详细信息。有了服务订阅关系，业务和服务之间的调用管理系统变得透明化，不合理的接口依赖、调用关系一目了然。

分而治之

      当垂直应用越来越多时，应用之间的交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的底层微服务，使前端应用更快的响应多变的市场需求。

      应用的差分分为水平拆分和垂直差分两种，水平差分以业务领域为维度，抽象出几个不同的业务域，每个业务域作为一个独立的服务中心提供对外服务。领域服务可以独立地伸缩和升级，快速的响应需求变化，同时与其他业务领域解耦，它的原理如下图所示：

  

 

图--水平切分

    应用的垂直拆分主要包含前台逻辑拆分、业务逻辑和数据访问层拆分，拆分之后效果如下图所示：

 

 

图--垂直切分

    经过水平和垂直拆分之后，可以将复杂的巨无霸应用拆分成多个独立的微服务，系统从大道小，分而治之。

敏捷交付

     软件解决方案的敏捷性，指的是它能快速进行变更的能力，敏捷性是微服务架构特性中最显著的一点：敏捷性的产生，是将运行中的系统解耦成一系列功能单一服务的结果。微服务架构能够对系统中其他部分的依赖加以限制，这种特性能够让基于微服务架构的应用在应对BUG或是对新特性需求时，能够快速地进行变更。这一点与传统的垂直架构悄悄相反，在传统架构中经常发生的一种情况是：“要对应用程序中某个小部分进行变更，就必须对整体架构进行重新的编译和构建，并且进行重新的全量部署。”

微服务架构解析

    微服务架构（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

    传统架构和微服务架构的对比如下图所示：

 

 

图：传统框架与微服务框架的对比图

微服务架构划分原则

      实际上微服务本身没有严格的定义，划分原则也有不同的实践，但是比较通用的划分原则是：微服务通常是简单、原子的微型服务，它的功能单一，只负责处理一件事，与代码行数并没有直接关系，与需要处理的业务复杂度有关，有些复杂的功能，尽管功能单一，但是代码量可能是成百上千行，因为不能以代码量作为划分微服务的维度。

微服务的“微”并不是一个真正可衡量、看的见摸得着的“微”。这个“微”所表达的是一种设计思想和指导方针，是需要团队或者组织共同努力找到的一个平衡点，在实践团队成员可以接受。

微服务总结起来就是小，且关注于做一件事情。

特点总结

     

      随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。负责应用被分解成多个更小的服务，每个服务有自己的归档文件、单独部署，然后共同组成一个复杂的应用。总结起来，微服务有如下的特点：

1）单一职责原则：每个服务应该负责单独的功能，正式SOLID原则之一。

2）独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级，每个服务都可以沿用着 “Art of Scalability” 一书定义的X轴和Z轴进行扩展。

3）支持异构/多种语言：每个服务的实现细节都与其他服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、工具和方法。

4）轻量级：微服务通常有轻量级的分布式服务框架承载，采用了P2P通信，无中心节点，性能可以线性增长；第三方软件依赖减少，减少类冲突和冗余依赖，集成和升级更方便。

 

    基于上述特点，微服务架构的有点总结如下：