微服务最强理论基础，堪称绝妙心法

前言

Building Microservices: Designing Fine Grained Systems 读书笔记。

本书偏理论而非实现，可作为内功心法，适合架构师或有经验的系统工程师。

常读常新。

---

前言

微服务是分布式系统提高细粒度服务（use of finely grained services）使用的一种 方式，在这种模式中，每个服务都有自己独立的生命周期，所有服务共同合作完成整体 的功能。

微服务主要是针对业务领域建模的（modeled around business domains），因此可以 避免传统分层架构（tiered architecture）的一些缺点。

微服务价格提供了越来越多的自治性（increased autonomy）。

1 微服务

Domain Driven Design：如何对系统建模。

领域驱动设计（DDD）、持续交付（CD）、按需虚拟化（On-demand virtualization）、基 础设施自动化（Infrastructure automation）、小自治团队（Small autonomous teams） 、大规模系统（Systems at scale）：这些都是微服务产生的前提。

微服务并不是凭空设计的，而是真实需求催生的。

什么是微服务？

微服务：小的、自治的、一起工作的服务。

• 小：专注、只做好一件事情很难确定多小才算小，但是比较容易确定多大就算大：如果你觉得一个系统该拆分了， 那它就是太大了
• 自治判断标准：对一个服务进行改动升级，不影响其他服务

主要好处

• 技术异质性（Technology Heterogeneity）
  • 不同组件可以采用不同语言、框架、数据库类型等等。综合考虑功能、性能、成本等 ，选择最优的方案
  • 新技术落地更方便
• 容错性（Resilience）
  • 容错工程的一个核心概念：bulkhead（防水壁）。一个组件出差，错误不应该瀑 布式传递给其他系统（cascading），做到错误隔离
  • 但也应该认识到，微服务（分布式系统）跟单体应用相比，会引入新的故障源（ sources of failure），例如网络故障、机器故障
• 扩展性（Scaling）
• 易于部署（Ease of Deployment）
• 架构和组织对齐（Organizational Alignment）
  • 多个小团队维护独立的较小的代码库，而不是大家一起维护一个很大的代码库
• 可组合性（Composability）
  • 单个服务可以同时被不同平台使用，例如一个后端同时服务 PC、Mobile、Tablet 的访 问
• 易于替换组件（Optimizing for Replaceability）

SOA 与微服务

面向服务的架构（Service-oriented architecture，SOA）是一种多个服务协同工作来提供 最终功能集合（end set of capabilities）的设计方式。这里的服务通常是操作系统中完全独立的进程。服务间的调用是跨网络的，而不是进程内的函数调用。

SOA 的出现是为了应对庞大的单体应用（large monolithic applications）带来的挑战。它的目的是提高软件的重用性（reusability of software），例如多个终端用户应用 使用同一个后端服务。SOA 致力于使软件更易维护和开发，只要保持服务的语义不变， 理论上换掉一个服务其他服务都感知不到。

SOA 的思想是好的，但是，关于如何做好 SOA，业界并没有达成共识。在我看来，很 多厂商鼓吹 SOA 只是为了兜售他们的产品，而对业界大部分人对 SOA 本身还缺少全面和 深入的思考。

SOA 门前的问题包括：通信协议（e.g. SOAP）、厂商中间件、对服务粒度缺乏指导、对在 哪切分单体应用的错误指导等等。愤青（cynic）可能会觉得，厂商参与 SOA 只是为他们卖 自家产品铺路，而这些大同小异的（selfsame）产品反而会削弱（undermine） SOA 的目标。

SOA 的常规实践经验（conventional wisdom）并不能帮助你确定如何对一个大应用进行拆分。例如，它不会讨论多大算大，不会讨论实际项目中如何避免服务间的过耦合。而这些没有讨论的东西都是 SOA 真正潜在的坑。

微服务源自真实世界的使用（real-world use），因此它对系统和架构的考虑比 SOA 要更 多。可以做如下类比：微服务之与 SOA 就像极限编程（XP）之与敏捷开发（Agile ）。

其他拆分方式

• 共享库（Shared Libraries）：语言、操作系统、编译器等绑定
• 模块（Modules）：模块/代码动态更新，服务不停。例如 Erlang

没有银弹

微服务并不是银弹，错误的选择会导致微服务变成闪着金光的锤子（a golden hammer）。微服务带来的挑战主要源自分布式系统自有的特质。需要在部署、测试、监控等方面下功夫 ，才能解锁服务器带来的好处。

总结

2 演进式架构师（The Evolutionary Architect）

软件工程和建筑工程的角色对比

计算机和软件行业很年轻，才六七十年。“工程师”、“架构师”（architect，在英文里和建 筑师是同一个单词）等头衔都是从其他行业借鉴过来的。但是，同样的头衔在不同行业所 需承担的职责是有很大差别的，简单来说就是：软件行业中的头衔普遍虚高，且对自己工 作成果所需承担的责任都很小。例如，建筑师设计的房子倒塌的概率，要比架构师设计的 软件崩溃的概率小得多。

另一方面，软件工程设计和建筑工程设计也确实有不同。例如桥梁，设计建好之后基本桥就 不动了，而软件面向的是一直在变化的用户需求，架构要有比较好的可演进性。

建筑设计师更多的会考虑物理定律和建材特性，而软件架构师容易飘飘然，与实现脱节，最 后变成纸上谈兵，设计出灾难性的架构。

架构师应具备的演进式愿景

客户的需求变化总是比架构师想象中来的更快，软件行业的技术和工具迭代速度也比传统行 业快得多。架构师不应该执着于设计出完美的终极架构，而更应该着眼于可演进的架构。

软件架构师的角色与游戏《模拟城市》（SimCity）里镇长（town planner）的角色 非常相似，做出每个决策时都需要考虑到未来。

人们经常忽视的一个事实是：软件系统并不仅仅是给用户使用的，开发和运维工程师也 要围绕它工作，因此系统设计的也要对开发和运维友好。

Architects have a duty to ensure that a system is_habitable_for developers too.

总结起来一句话：设计一个让用户和开发者都喜欢的系统。

那么，如何才能设计出这样的系统呢？

Zoning（服务或服务组边界）

架构师应该更多地关心服务间发生的事情，而不是服务内发生的事情。

Be worried about what happens between boxs, and be liberal in what happens inside.

每个服务可以灵活选择自己的技术栈，但如果综合起来技术栈太过分散庞杂，那成本也会非 常高，并且规模很难做大。需要在技术栈选择的灵活性和整体开发运维成本之间取得一个 平衡。举例，Netflix 大部分服务都是使用 Cassandra。

参与写代码的架构师（The coding architect）

架构师花一部分时间参与到写代码，对项目的推进会比只是画图、开会、code review 要 有效得多。

A Principled Approach

架构设计就是一个不断做出选择（折中）的过程（all about trade-offs），微服务架构给 我们的选择尤其多。

原则化（Framing）：Strategic Goals -> Principles -> Practices.

A great way to help frame our decision making is to define a set of principles and practices that guide it, based on goals that we are trying to achieve.

图 2-1 一个真实世界的原则和实践（principles and practices）的例子

最好提供文档和示例代码，甚至是额外的工具，来解释这些原则和实践标准。

The Required Standard

一个好的微服务应该长什么样：

It needs to be a cohesive system made of many small parts with autonomous life cy