锤子眼里全是钉？谈如何对现有系统进行微服务改造

 

 

1 什么是微服务架构？

微服务架构，主要是一种思想，并非具体的技术、框架、语言等。核心在于将现有系统拆分为功能明确，内聚性强，职责单一的微小部分，以服务形式对外提供，从而将原来的复杂大系统分而治之，以此降低整体复杂度，达到更好的可控性。

2 现有系统问题是什么，核心问题是什么，核心业务需求是什么？

传统应用系统架构通常为单体应用，表现为单进程，业务逻辑耦合。应用系统随着业务逻辑增加，功能增多，特性增强，会不断填充进新的需求处理逻辑，系统中也会遍布各种补丁式的、面条式的代码。这样，开发人员在面对功能的修改和扩展时，会发现代码理解困难，进一步导致逻辑添加困难，遗留的各种特殊处理逻辑混合，容易代入不易察觉的问题。整个系统的测试也因此变得困难，一个小修改可能需要整体功能的覆盖测试，而且问题不容易测出，隐匿风险大。这种不断填充式的逻辑，还会导致测试用例编写困难，更增加问题潜伏的风险。更进一步，随着代码体积的增加，会导致系统构建编译时间长，学习成本增加，特别是新人很难快速上手，隐形成本大增。随着恶性循环，对旧代码的依赖会越来越强，新的框架语言也很难加入，改造难度增大。整个系统部署风险也很大，需要停用现有系统，无法做到无缝对接，无缝过渡，不利于业务产品的迭代，系统本身升级成本和风险也比较大，如此，带来的是整体运维成本增加。最终，整个系统变得臃肿庞大，成为一个行动迟缓的怪兽，可维护性，可扩展性，灵活性等也再无从谈起。

通过上面问题的介绍，可见微服务对于需求易变的业务类系统，尤其适用。

3 结合微服务改造有什么好处？适不适合用微服务改造？或者说，为什么适合用微服务进行改造？如何改造？

为解决上述传统应用开发维护中的问题，提出了微服务架构思想。微服务的形式及好处如下：

（1）微服务，微表示小，细粒度，这点从名称上直接体现出来。将应用拆成小粒度服务，每个服务单独开发测试部署运维，服务本身还是体现高内聚低耦合特性。一个服务完成一类或者一个特定业务功能。这里涉及到多小才算合适，才算微，这是实践中特别需要把握，重点关注的一个度。

 （2）作为一个服务，本身是可以采用适合该服务特性及贴合其承载业务特点的语言和框架的。服务也可以由单独的团队来构建、开发、测试、维护等等，甚至可以从UI到底层，都由该团队负责了，只要这个服务显著的内聚，低耦合。这样，每个微服务就是轻量级的一个应用了，占用单独的进程资源，可以拥有自己的数据存储，天然支持分布式部署，方便适用集群架构，可灵活扩容增量。可见，这是一种思想的体现。这种方式，对框架和语言的要求放宽了，自然也对团队组建的要求降低了，从而更容易快速上手，更容易快速应对变化，有敏捷的思想包含在里面。

 （3）一个大系统拆分后，肯定会构建成多个微服务。原来是一个整体对外的业务系统，拆分后仍然需要体现这些服务是为一个大整体系统而构建和服务的，每个服务是大系统中的一部分。这种业务需求内生的就要求这些微服务需要交互，通信。微服务之间如何方便、高效、灵活、可靠、可扩展的通信？其实有许多现成方案可供选择。对于分布式、大数据量、异步特点的通信，消息队列是优先选择。对于裸机内、局域网，可采用RPC做同步通信。对于跨平台、跨语言，同步可采用HTTP的RESTfull方案。这些都需要根据具体场景、具体需求、具体分析，因地制宜的实施。

显然，拆分服务后，简化了功能开发，这是分而治之带来的复杂度降低。从面向未来来看，开发可以轻装上阵，新人也比较容易上手，语言框架可以选择最适合的，团队搭建成本降低；修改面对的功能范围会因为单一职责而比较明确；测试也会因为单一职责而受益；更重要的是，因为容器化的构建、部署技术的成熟，整个修改测试上线过程可以实现无缝切换，极大的降低了运维成本。对服务本身而言，因为不担心对现有系统运行的影响，架构扩展可以更加从容，而且基于单一职责和容器部署技术，加之分布式技术的使用，集群搭建更加方便，系统的扩容增量也不再是问题。

但是服务多了后，通信就成为整体系统的制约因素。一方面，跨进程、跨主机、跨语言的通信，比起单体应用内部的直接调用或线程间通信效率要低很多；其次，当服务多了后，通信链条自然就变多了，极端情况，每一个服务都需要同其他所有服务通信，这使得通信链条的调试，问题点的定位，功能的验证变得复杂了；最后，服务增多，服务间通信链路变多后，对服务性能要求会提高，这与服务对外提供接口的形式又存在矛盾。而且，相互调用情况的普遍化会使得整体系统的设计复杂度陡然提升。所以，这一块还是需要综合考虑，整体平衡的。另外，分布式技术本身的复杂度也会从逐渐体现出来，如果不能很好的驾驭这块，反而会成为整个系统的梦魇。

虽然微服务有很多好处，但是我们也看到了，微服务可能带来额外的问题，所以系统适不适合用微服务来改造，还需要看具体存在的问题。如果适合用微服务这个“药”来治，那就坚决将微服务思想贯彻到底，否则，也别勉强，别硬进行微服务化。因为，微服务并不是包治百病的神药。在回答这个问题之前，我们先看看那些地方或那些情况不适合用微服务进行改造，或者说选择微服务解决不了存在的问题。也就是我们需要进一步看看微服务方案存在那些缺点，这些缺点或许会给我们一些启发。俗话说，有得就有失，有利就有弊，要趋利避害。首先，微服务的分布式会带来很大的复杂性问题，如果没有丰富的经验，问题可能会无法收敛，从而导致改造失败。其次，服务调用路径确定，服务间的依赖管理，服务间依赖测试以及性能热点追踪等，每一个都会是改造之路的绊脚石，要有心理准备。再次，跨进程、高通信成本、高运维要求、高组织架构成本（服务之间有通信，组织之间就必然有沟通，资源就必然涉及有协调），也是需要特别关注的。最后，上述问题延伸一下，对实时系统而言，微服务改造可能会带来不可预测的潜在风险。所以说，微服务潜在的适用于大型系统开发，通过上述分析，道理是显而易见的。

因此，对一些不算太复杂，中等程度，已经在团队内磨合维护，运转正常的程序来讲，进行微服务改造要尤为慎重，除非有非常坚定的难以拒绝的理由。

回到问题本身。最后研判后，如果得出适合进行微服务化改造的结论，那么该如何实施？具体方案实施中遇到了那些问题，是如何解决的，这些也是需要好好总结的。这里给出别人的一个微服务改造实践流程：

1 最小修改，移到新的环境中

2 功能剥离，从现有中移动已有接口

3 数据解耦，剥离数据，独立提供服务

4 数据同步

5 迭代替换，业务功能逻辑加数据，等价替换。

下面也是别人在微服务实践过程中总结的有益经验。

四大切分原则：

1 业务先行

2 由粗到细

3 避免耦合

4 持续改进。

四大切分要求：

1 根据业务模块划分服务种类

2 服务独立部署，相互隔离

3 服务间轻量级接口

4 服务高可用，幂等原理

四大特点：

1 服务颗粒化

2 责任单一

3 运行隔离

4 自动管理

四大挑战：

1 运维要求高

2 分布式复杂性

3 服务依赖强

4 通信成本高

作为一个微服务架构师，系统改造专家，既需要全面通透的理解原系统，从而可以庖丁解牛式的分解原系统，也需要吃透微服务的精髓，以便高瞻远瞩的布局新系统。