第2章

微　服　务

我们所负责的系统是否适合进行微服务化改造？如果适合我们应该如何着手将现有系统一步步微服务化？在本章我们将围绕微服务的概念、特点、设计模式，以及如何将一个单体拆分为微服务这几个主要的关键点，来了解一下什么是微服务。

2.1　为何要做微服务

2.1.1　架构设计新理念：做好隔离

无论是微服务还是单体服务，都是一种项目的架构方式，项目架构首先要确认架构原则是什么，以及目标是什么，答案很简单，架构原则需要根据公司的目标来制定，也就是说架构原则应该与公司的发展愿景和使命相符。架构目标就是盈利，盈利的方法有很多，通过降低成本换取利益最大化是盈利的一个主要途径。而如何能实现降本增效的目的呢？其实无论是单体服务还是微服务，都可以从可用性、可扩展性、质量、成本、效率、响应时间这几个维度入手。微服务也是把单体解构之后，变成一个个构建小、发布快的小服务，从而提高可用性，增强可扩展性，最终完成降本增效的目的。

在这里，我们列出15个最常用的架构原则，这些原则并不是在所有的设计中都必须涉及，而是供客户剪裁，由客户根据项目的特性增加或者删除某项或某几项原则。我们概括地讨论这些原则，并着重考虑其与微服务架构设计的相关性。

1）N+1设计：确保系统发生故障时，至少有一个冗余的实例。

2）回滚设计：确保系统可以回滚到以前发布过的任何版本。

3）禁用设计：确保一些具有高风险的系统功能能够通过开关来禁用，这能为修复赢得时间。

4）监控设计：在设计阶段就必须考虑监控，而不是在实施完成之后。监控做得好，将为系统的可扩展性预留空间。

5）设计多活的数据中心：确保系统可在地理上隔离灾难和危机。

6）使用成熟的技术：只用确实好用的技术。

7）异步设计：只有在确实有必要的情况下才使用同步设计，以增加系统的可扩展性。

8）无状态系统：只有在确实有必要的情况下才使用状态，状态耗费资金，降低处理能力、可用性和可扩展性。

9）水平扩展而非垂直升级：永远不要依赖更大、更快的系统。

10）设计至少要有两个步骤的前瞻性：在扩展性问题上提前考虑好下一步的行动计划。

11）非核心的购买：如果不是最擅长的，也提供不了差异化的具有竞争优势的功能，则直接购买。

12）使用大规模量产的商品化硬件：只有在确实有必要的情况下才定制硬件。

13）小构建、小发布、快试错：不断迭代，让系统不断地成长。

14）自动化：设计和构建自动化的过程，如果机器可以做，就不要依赖人。

15）隔离故障：实现故障隔离设计，通过断路保护避免故障传播和交叉影响。

以上就是我们常用的一些架构原则，我们也可以用图2-1这样的形式直观地了解微服务的架构原则。在技术高速发展的今天，架构设计理念也在发生着变化。例如，平均修复时间和平均故障间隔时间是做系统时必然会面对的两个指标，那么这两个指标哪个更重要一点？其实这个问题没有标准答案，历史经验更多是关注平均故障间隔时间，选用很健壮的数据库，选择高可用的中间键，购买小机，提高高可用性，增加系统的安全设置，目的都是尽量少出错、不出错，让错误在更早的时候及时得到处理，这一切都是为了提升平均故障间隔时间。但到了现阶段，当我们购买的X86越来越多，甚至系统所占的机房和数据中心不再是一个的时候，我们的理念也随之发生了变化：我们认为出错是必然的。有运维经验的人都知道，如果有上百台的X86，那么出错是必然的，很难像原来的小机时代，能够实现尽量不出错。

既然出错是必然的，那么我们就需要在设计初期考虑如何能将出错造成的影响降到最小，这时做好隔离就尤为重要了。无论是从虚拟机、容器层面，还是到现在从数据和应用两个层面切分做微服务，所有的这一切都是为了实现隔离，让一个点出错产生的影响最小，并更快恢复，最大限度地降低出错对业务的影响，这也是目前我们在架构设计理念的显著变化。

图2-1　微服务架构原则

微服务是实现隔离的重要手段，但故障隔离不是免费的，也未必是便宜的。那么何种情况下需要优先考虑通过微服务实现隔离呢？答案取决于该系统的特定需求、增长率、不可用率和客户期望等一系列因素。如果微服务故障隔离做好了，后面会得到很好的回馈。

在这里，我们提供一些简单的原则来帮助大家制定故障隔离方案。

1）泳道与盈利原则：一定要确保与盈利关系最密切的事情和可能失败及有需求限制的其他系统适当地隔离，并创建泳道。例如，如果是一个商务系统，影响业务最关键的就是订单和收费这两个与钱关系最紧密的模块，我们需要考虑将其从硬件、中间应用层和最上层的网络层都实现隔离。

2）隔离频繁出错组件：如果有的模块特别容易出错，那么这个模块也具备率先考虑通过微服务实现隔离的特质。

3）泳道与天然隔离：客户边界是最好的泳道隔离锁，这种分割沿着客户的边界实施。分割通常先在存储或数据库层完成，再创建一条从请求到数据库并从数据库返回客户的完整泳道。

隔离会耗费成本和资源，共享将获得成本效益，所以我们需要权衡隔离。在大多数情况下，单一泳道可运行多个应用。但如果某个服务特别忙，那么可以给它分配一个专用泳道；如果大部分服务利用率都很低，那么可以把它们都分配到一个泳道。

如何进行故障隔离，有几条重要的原则。

1）原则1：绝不共享或者尽量减少共享。包括共享网络、共享硬件、共享URL、共享数据库等一切资源，泳道共享越少，其故障隔离度就越高。

2）原则2：不跨越泳道。同步通信从不跨越泳道，如果跨越了泳道，那么边界划分就会不正确。

3）原则3：交易发生在泳道。不能建立多服务泳道，那些服务通信将违反原则2。如果我们在白板上画一个从用户指向最后一个功能组件的箭头，该箭头不应该跨越泳道。

我们都了解传统行业中的城市规划师要规划城市整体架构，要充分考虑水、电各种区块；而建筑师要负责建筑图纸的设计，最终将图纸上的建筑落地实现。那么，如果将软件架构师与建筑师、城市规划师类比，哪个角色与软件架构师更相符呢？有的人认为是城市规划师，也有人认为是建筑师，当然也有人认为软件规划师兼具两者的特点，因为做系统要考虑很多因素，要考虑整个资源的共享。

现在的系统更像高度复杂的城市，而不是单独的房屋，所以软件架构师更像城市规划师，他的职责是对城市进行规划，确定每个区域应该做的事情，这些区域应当达到统一的规范要求，又要具备随时扩张或缩减的灵活性。同时，他还应当保证这种划分适合专业人员在对应区域工作。明白了这一点，就可以明白版本管理、持续集成、自动化测试、自动化发布、服务治理、详尽监控等“磨刀工夫”的价值，没有这些工作，就谈不上微服务的质量和保障级别，也就无法驾驭微服务的体系。

由此，也很容易明白软件架构师在这个时代所要面对的挑战。一方面，软件架构师没有现成的足够强大的集成工具，只能靠一堆“稀松平常”的工具组装出整体可靠的系统；另一方面，要深入理解业务，把业务拆散成边界清晰的概念，以“高内聚低耦合”的服务分而治之，还必须考虑实现的限制——“高内聚低耦合”的原则人人都知道，如果没有可靠的分布式事务管理机制，就不得不把并非“高内聚”的模块聚合起来，但又要担心业务边界模糊的风险。RESTful固然优雅，但有时候又不得不使用RPC通信，所以又要提防RPC带来的强绑定，客户端、服务器端同步更新等很多问题。

这一切设计、权衡、决策并没有成型的理论和学说可以依靠，通常只能完全依赖软件架构师的经验、理解、思考。所以困难很大，风险也很大，如果做得好，收益也是非凡的。而这恰恰是软件架构师的价值所在。