华为架构师经验：从单体架构到微服务的服务化演进之路

本次分享的技术大纲如下：

• 传统应用开发面临的挑战
• 服务化实践
• 服务化不是银弹
• 服务化架构的演进方向

一 、传统应用开发面临的挑战

挑战1-- 研发成本高

 

主要体现在如下几个方面：

• 代码重复率高

在实际项目分工时，开发都是各自负责几个功能，即便开发之间存在功能重叠，往往也会选择自己实现，而不是类库共享，主要原因如下：

1. 从技术架构角度看，传统垂直架构的特点是本地API接口调用，不存在业务的拆分和互相调用，使用到什么功能就本地开发，非常方便，不需要过度依赖于其它功能模块；
2. 从考核角度来看，共享很难推行。开发只需要对自己开发的模块交付质量负责，没有义务为他人提供并维护公共类库，这个非常耗费成本；
3. 时间依赖很难把控：对于公共类库的使用者而言，依赖别人提供此功能，但是功能提供者可能有更重要的事情在做，提供时间无法满足使用者。与其坐等别人提供，还不如自己开发效率高；

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

• 需求变更困难

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

 

 

 

 

 

• 无法满足新业务快速创新和敏捷交付

 

挑战2-- 运维效率低

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

 

当垂直应用越来越多时，连架构师都无法描述应用间的架构关系，随着业务的发展和功能膨胀，这种架构很容易发生腐化。

• 测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署
• 可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展
• 可靠性差：某个应用BUG，例如死循环、OOM等，会导致整个进程宕机，影响其它合设的应用

如何解决传统单体架构面临的挑战？

解决对策：1、拆分 2、解耦 3、透明 4、独立 5、分层。

• 拆分：对应用进行水平和垂直拆分，例如商品中心、计费中心、订单中心等。
• 解耦：通过服务化和订阅、发布机制对应用调用关系解耦，支持服务的自动注册和发现
• 透明：通过服务注册中心管理服务的发布和消费、调用关系
• 独立：服务可以独立打包、发布、部署、启停、扩容和升级，核心服务独立集群部署
• 分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

二、服务化实践

服务的订阅发布机制

它的核心理念是实现服务消费者和服务提供者的解耦，让服务消费者能够像使用本地接口一样消费远端的服务提供者，而不需要关心服务提供者的位置信息，实现透明化调用。

关键技术点：服务的订阅、发布机制、服务的健康状态检测和高HA。

 

常用的服务注册中心有Zookeeper、ETCD，以及基于数据库的配置中心。

大家在技术选型的时候，需要根据自己的业务实际情况进行选择。例如超大规模集群，服务实例数超过10W，Zookeeper就会存在性能问题。

现在开源的分布式配置服务很多，如无特殊需求，建议选择开源方案。

服务化实践-零侵入

实际上，完全的零侵入很难做到，即使是