微服务架构技术调研＜2＞--为什么要向微服务架构转型

引言：

由于公司商业上有实打实的需求和场景，倒逼产品开始思考架构升级，以适应这种商业环境的快速变化。架构师在进行技术选型或者架构升级前，需要做大量技术调研、竞品分析，《微服务架构综述》则是对服务化架构技术调研产生的调研报告，将会从如下三个角度分析微服务架构的“前生今世”，从而为产品团队的技术转型找到一些理论依据：

1. 什么是微服务架构，其与传统架构区别联系
2. 为什么要向微服务架构转型
3. 微服务架构实践

#为什么要向微服务架构转型

##为什么需要技术架构升级？

《人人都是架构师》书中给出的架构升级的建议[4]：

 齐商银行决定行级系统向微服务架构转型报告中提到的原因[5]： 

（一）各应用系统之间功能和数据相互孤立，存在功能重复建设和数据不对称的现象，难以满足多场景、快速迭代的业务发展需要；

（二）单体系统内部紧耦合，需求升级对其他功能模块的影响难以评估，加大了开发、测试的工作量和周期；

（三）集中式架构高可用性不足，所有业务都运行在一台主机设备上，一旦发生故障就可能影响到业务的连续性。

##传统架构痛点

• 开发效率低下，产品越来越难维护

当单体应用的代码越来越多，业务越发复杂。再加上团队人员的更迭，造就越来越多的“屎山”，历史遗留代码。项目越发难以维护。

• 团队协作开发成本高

早期在团队开发人员只有两三个人的时候，协作修改代码，最后合并到同一个master分支，然后打包部署，尚且可控。但是一旦团队人员扩张，超过5人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。

• 系统高可用性差

因为所有的功能开发最后都部署到同一个WAR包里，运行在同一个Tomcat进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个WAR包中部署的功能。比如我经常遇到的一个问题，某段代码不断在内存中创建大对象，并且没有回收，部署到线上运行一段时间后，就会造成JVM内存泄露，异常退出，那么部署在同一个JVM进程中的所有服务都不可用，后果十分严重。

• 发布上线速度变慢

特别是对于Java应用来说，一旦代码膨胀，服务启动的时间就会变长，有些甚至超过10分钟以上，如果机器规模超过100台以上，假设每次发布的步长为10%，单次发布需要就需要100分钟之久。

##微服务架构特点

• 服务拆分粒度更细

微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。

• 服务独立部署

每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个Docker实例，每个Docker实例可以部署一个微服务的代码。

• 服务独立维护

每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。

• 服务治理能力要求高

因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。

### 微服务架构如何解决传统架构的痛点

亚马逊给出的解释：

通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。

使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

James Lewis和Martin Fowler对微服务架构相比传统架构优势描述：

• 服务简单，只关注一个业务功能

在James看来，传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。

而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。

• 每个微服务可由不同团队开发

传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。

• 微服务是松散耦合的

微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式。

• 可用不同的编程语言与工具开发

传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。

总结：

微服务架构以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分解，采用分而治之的方法，达成用户需要的功能指标，提高开发效率、部署便捷性，并同时满足用户对高可用、高并发、可伸缩、可扩展，可维护和安全性的非功能质量的要求。

###微服务架构带来的挑战

James的文章在社区引起了广泛的讨论，Contino[7]公司的CTO Benjamin Wootton撰文表示微服务并没有想象中的那么好，并建议开发者在选用此架构时一定要慎重。

Benjamin认为微服务架构时可能会面临下面一些挑战[6]：

• 运维开销

更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

• DevOps要求

使用微服务架构后，开发团队需要保证每一个Tomcat集群可用，保证每一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。

• 隐式API依赖

服务和服务之间通过API来“联系”，当某一个服务更改API格式时，可能涉及到此接口的所有服务都需要做调整。

• 重复劳动

在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

• 分布式系统的复杂性

微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。

• 事务、异步、测试面临挑战

跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。

齐商银行决定行级系统向微服务架构转型报告中提到的困难[5]：

（一）微服务架构的关键技术选型是落地的关键，在当前市面上存在多个流行的微服务技术栈，如何在其中选择适合自己的，对于缺乏经验的团队是一个考验；

（二）微服务架构自身存在明显的优势，但同时也带来诸多新问题，如分布式架构固有的复杂性，对项目实施和运维人员提出了更高要求等，哪些系统适合采用微服务架构需要慎重选择；

（三）现有系统中大部分是引入外部厂商的产品，系统架构不统一，难以统一规划，如何在架构转型中对存量系统的服务进行构建等。