微服务是传统企业电商解决方案的银弹吗?

近几年，微服务成为最流行的技术名词之一，尤为受到亚马逊、阿里等电商巨头的影响，不少传统企业在实施电商过程当中也纷纷往微服务架构靠拢，相比单体架构，微服务确实有不少优势，就像 Sam Newman 在“Building Microservices”[1] 中所阐述的那样：

• 技术异构性

• 弹性

• 伸缩性

• 容易部署

• …

可是计算机科学做为一门平衡的科学，任何技术架构在带来收益的同时也会有其局限性，做为系统架构师或者决策人员，必定要对此有清醒的认识。本文将重点阐述成功实施微服务的先决条件，所面临的主要挑战和风险，传统企业在实施电商过程当中的决策要素以及正确的实施策略。BTW，做者本人对微服务没有任何成见，我在 amazon 工做期间一直接触的就是微服务架构，并且本人也是 Adrian Cockcroft 的超级粉丝。因此各位微服务控们千万不要拍砖。

成功实施微服务的先决条件

通常而言，成功实施微服务的先决条件包括：

• 匹配的组织架构

• 实力雄厚的技术团队（包括开发 / 测试 / 运维）

• 清晰的业务边界

其中第一条换个洋气点的说法就是康维定律（Conway’s Law[2]），这是我最喜欢的定律之一，现实中接触到的各个案例无一例外：

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

康维定律简单来讲，就是任何软件都反映出制造它的团队的组织结构，这是由于人们会以反映他们组织形式的方式工做。 换句话说，采用微服务架构的组织结构也应该是分散的。看看现实中成功实施微服务的那些公司：Amazon、Netflix、阿里那个不是分散的组织结构。

至于后面两条的缘由我将在下面一节深刻探讨。

挑战和风险

更长的学习曲线

主要包括：

• 除了须要了解业务逻辑外，也须要花大量精力去学习底层微服务框架提供的各类服务并听从其契约，如下图为例，为了实施一个基于微服务架构的电商，技术团队须要掌握如下：

• 业务逻辑及其之间的接口

• 基于容器的部署和工具，好比 Docker、Kubernetes 等

• 微服务框架自己的学习，包括 API 网关、服务发现和注册机制、熔断、分布式配置等等

• 甚至背后的理论 / 设计模式，诸如 CAP、BASE 等等

更多的开发 / 测试工做

例如：

• 由于常见微服务架构都是每一个服务拥有本身的数据库，致使须要跨表实现统计报表等功能将变得很复杂

• 对于哪些须要依赖其余微服务的微服务开发及测试，你不得不在本地也安装全部须要依赖的微服务，即便采用 Docker 容器，根本问题并无改变，与单体服务的开发相比较而言，开发测试变得很繁琐

• 代码自己也要听从微服务框架的各类契约，例如一个使用 Hystrix 熔断机制的代码以下：

@Service

public  class MyService {

@Autowired

RestTemplate restTemplate;

@HystrixCommand(fallbackMethod = "errorHandler")

public String myService(String name) {

return restTemplate.getForObject("http://MYSERVICE/myservie?name="+name,String.class);

}

public String errorHandler(String name) {

return  "There is an error for service "+name;

}

}复制代码

重构的代价

因为各类缘由（特别是在对业务的理解不够或者业务变更频繁的状况下），已经上线的微服务发现并不合适从而须要重构，例如须要把计价服务从新合并回产品服务，至少遵循如下步骤（请参考下图）：

1. 首先在产品数据库中创建与计价有关的表，创建导入工具吧计价数据库中的数据导入到产品数据库中，须要注意的是，若是产品服务和计价服务采用不一样的数据库，还须要额外的开发成本编写导入工具。在本步骤完成后，产品服务并不提供任何计价功能，只是全部计价服务中的数据会被不断（同步或异步）导入到产品数据库中。

2. 在产品服务中引入计价功能并暴露相应接口，在充分测试后配置 API 网关（如 Zuul 或者 Istio）对计价功能调用进行分流，期间全部流入老的计价数据库的数据依然会被导入到产品数据库中。

3. 通过一段时间的金丝雀发布后，最终全部的计价功能调用都进入产品 / 计价服务，老的计价服务和相应的数据库被卸载。

固然这是在很是理想的状况下，现实状况比这个复杂的多，例如部分须要合并部分须要拆分，采用不一样的编程语言，采用不一样的数据库技术，其它微服务对相关微服务的依赖等等。另外典型的微服务架构中不一样的微服务由不一样的组 / 部门去维护，相关的沟通协做也是一个不容忽视的成本，因此在业务不稳定或者理解不充分的状况下贸然实施微服务的代价是很是巨大的！

更严谨的设计

微服务架构比单体服务更容易发生问题，不可是由于分布式计算自己复杂性带来的各类问题（如一致性问题），并且各类流行的微服务框架都有这样那样的坑，以电商业务为例，用户 1 须要上架一批新产品，为了提升并发性以及下降服务之间的耦合度，当前的微服务架构采用消息总线去通知计价服务 / 仓库服务 / 产品服务进行相应处理，不幸的是，因为消息的异步性，极可能对于某个产品而言，产品服务最后被通知到，期间若是用户 2 查询到了对应的库存但却发现相关的产品不存在（以下图所示），这显然违反了因果一致性（casual consistency）！

纠错的难度

想象一下订单服务的实现须要调用仓库服务，计价服务，支付服务等多个服务，中间任何一个环节出错都将致使订单处理失败，有时为了提升处理的并发量，每每采用基于消息总线的异步方式，这样想作到快速定位到错误根源对开发人员是一个不小的挑战，通常而言，咱们不得不从两个方面入手：

• 应用级别的关联，全部异步调用都必须引入消息标识关联

• 借助于微服务框架的分布式追踪机制，日志聚合等功能（如 zipkin，CloudWatch 等）

即使这样，出错调试的困难度和须要的时间也和单体服务不是一个量级的，并且大部分状况下，在单体服务中很容易重现并在本地经过单步跟踪快速解决的问题，对于微服务而言就变得不那么容易了。

依赖自动化的部署能力

在不少介绍微服务架构优势的文章中，常见的一条就是“易于部署”，实际上之因此“易于部署”，是拿单个“微服务“和单体服务相比较而言的，可是部署构成企业业务的几十个甚至上百个微服务的整体复杂度绝对比单体服务大的多，这就是为何全部基于微服务架构的应用都必须依赖自动化的部署能力，这对体术团队提出了两方面要求：

• 掌握自动化运维工具（如 Ansible）和相关的设计模式 (如服务器提供模式、服务器模版管理模式、基础架构定义模式等 [3])

• 微服务自己是快速部署匹配的，若是不是则须要进行重构 [4]。

业务方面的思考

从业务角度咱们必须思考如下这些问题：

• 你的业务体量到底有多大，会不会成长为相似于 / 接近于 Amazon/Netflix/Google/ 阿里 / 腾讯这些巨头体量的下一个巨头？

• 若是会，那么多长时间，几年仍是几十年？

• 实施电商后的产品升级 / 运维 / 扩展谁来作，可否提供足够的技术实力来应付微服务框架中的各类潜在风险

• 对业务的理解是否很是深入，仍是只停留在初级阶段？

• 公司组织结构是否有利于实施微服务架构？

• 是否有其余更为简单的解决方案

总之，做为系统架构师或者决策人员，咱们要作的就是透过“绚丽包装”的外表理解各类技术架构的本质从而避免过分设计给企业带来巨大的风险，在这点上 Jeff Dean 在其稳重“challenges in building large-scale information retrieval systems”中的经典名言值得咱们借鉴 [5]：

Design for ~10*growth, plan to rewrite before ~100*

演进路线

Martin Fowler 在其“MonolithFirst”一文 [5] 中明确指出：

• 几乎全部成功的微服务案例所有来源于业务足够复杂的单体服务

• 几乎全部不成功的微服务案例都是直接从头开发

实际上做为传统行业实施电商一个稳妥的方案是从单体开始，随着业务变得愈来愈复杂逐步慢慢演进到微服务，具体来讲：

• 单体服务的实施中须要采用良好的编程习惯，使得整个系统模块化并且业务边界清晰，若是一开始对业务不太熟悉，这须要不断的重构。

• 单体服务自己应该尽可能遵循云部署的那些基本原则，诸如无状态、经过环境变量注入配置信息等 [4]。

• 在电商业务变得足够复杂的状况下，逐步对有关服务进行拆分，须要注意的是此处只是逻辑上的拆分

• 增强对自动化运维能力的建设。

• 最终随着企业组织结构的逐步调整过渡到微服务架构。

结论

微服务的出现给传统企业实施电商业提供了强大 / 灵活 / 敏捷的框架，但同时也对不管技术仍是业务上都提出了更高 / 更严格的要求，不重视这些潜在风险将带来巨大风险，因此微服务不是企业电商解决方案的银弹，一般只有采起更为务实严谨的演进路线才能实现咱们的目标。

我大概在 2006 年开始参与架构设计，原觉得学习架构就像学习编程语言同样，先了解基本的语法，再研究细节和原理，而后实践一下就可以快速掌握。 但真正深刻后才发现，架构设计的难度和复杂度要高不少。

从最先开始接触架构设计，到自我感受完全掌握架构设计的精髓，我至少花费了 8 年的时间。 我曾经觉得是本身天资愚笨才会这样，后来我带了团队，看到几乎每一个程序员在尝试架构设计的时候，都面临着我曾经遇到过的各类困惑和瓶颈。

今天，我想把我过去全部的经验都分享在裙69-75-79-75-1里，里面都是我精心录制成视频供你们免费下载，但愿能帮你快速成为一名架构师。

参考资料

1. Building Microservices: Designing Fine-Grained Systems, Publisher: O'Reilly Media; 1 edition (February 20, 2015)

2. https://en.wikipedia.org/wiki/Conway%27s_law

3. Infrastructure as Code: Managing Servers in the Cloud, Publisher: O'Reilly Media; 1 edition (June 27, 2016)

4. https://12factor.net

5. https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf

6. https://martinfowler.com/bliki/MonolithFirst.html