*** CTO 基于五个简单的原则为精心设计的微服务提供建议。
对于从微服务开始的团队来说，***的挑战之一就是坚持金发女孩原则（该典故来自于童话《金发姑娘和三只熊》）：不要太大，不要太小，不能太紧密耦合。之所以是挑战的部分原因是会对究竟什么是设计良好的微服务感到疑惑。
数十位 CTO 通过采访分享了他们的经验，这些对话说明了设计良好的微服务的五个特点。本文将帮助指导团队设计微服务。（有关详细信息，请查看即将出版的书籍 Microservices for Startups，LCTT 译注：已可免费下载完整的电子版）。本文将简要介绍微服务的边界和主观的 “规则”，以避免在深入了解五个特征之前就开始指导您的微服务设计。
微服务边界
使用微服务开发新系统的核心优势之一是该体系结构允许开发人员独立构建和修改各个组件，但在***限度地减少每个 API 之间的回调数量方面可能会出现问题。根据 SparkPost 工程副总裁 Chris McFadden 所说，解决方案是应用适当的服务边界。
关于边界，与有时难以理解和抽象的领域驱动设计（DDD，一种微服务框架）形成鲜明对比，本文重点介绍了和我们行业的一些*** CTO 一同建立的明确定义的微服务边界的实用原则。
避免主观的 “规则”
如果您阅读了足够多的关于设计和创建微服务的建议，您一定会遇到下面的一些 “规则”。 尽管将它们用作创建微服务的指南很有吸引力，但加入这些主观规则并不是思考确定微服务的边界的原则性方式。
“微服务应该有 X 行代码”
让我们直说：微服务中有多少行代码没有限制。微服务不会因为您写了几行额外的代码而突然变成一个独石应用。关键是要确保服务中的代码具有很高的内聚性（稍后将对此进行更多介绍）。
“将每个功能转换为微服务”
如果函数基于三个输入值计算某些内容并返回结果，它是否是微服务的理想候选项？它是否应该是单独可部署应用程序？这确实取决于该函数是什么以及它是如何服务于整个系统。将每个函数转换为微服务在您的情景中可能根本没有意义。
其他主观规则包括不考虑整个情景的规则，例如团队的经验、DevOps 能力、服务正在执行的操作以及数据的可用性需求。
精心设计的服务的 5 个特点
如果您读过关于微服务的文章，您无疑会遇到有关设计良好的服务的建议。简单地说，高内聚和低耦合。如果您不熟悉这些概念，有许多文章关于这些概念的文章。虽然它们提供了合理的建议，但这些概念是相当抽象的。基于与经验丰富的 CTO 们的对话，下面是在创建设计良好的微服务时需要牢记的关键特征。
#1：不与其他服务共享数据库表
在 SparkPost 的早期，Chris McFadden 和他的团队必须解决每个 SaaS 业务需要面对的问题：它们需要提供基本服务，如身份验证、帐户管理和计费。
为了解决这个问题，他们创建了两个微服务：用户 API 和帐户 API。用户 API 将处理用户帐户、API 密钥和身份验证，而帐户 API 将处理所有与计费相关的逻辑。这是一个非常合乎逻辑的分离 —— 但没过多久，他们发现了一个问题。
McFadden 解释说，“我们有一个名为‘用户 API’的服务，还有一个名为‘帐户 API’的服务。问题是，他们之间实际上有几个来回的调用。因此，您会在帐户服务中执行一些操作，然后调用并终止于用户服务，反之亦然”
这两个服务的耦合太紧密了。
在设计微服务时，如果您有多个服务引用同一个表，则它是一个危险的信号，因为这可能意味着您的数据库是耦合的源头。
这确实是关于服务与数据的关系，这正是 Swiftype SRE，Elastic 的负责人 Oleksiy Kovrin 告诉我。他说，“我们在开发新服务时使用的主要基本原则之一是，它们不应跨越数据库边界。每个服务都应依赖于自己的一组底层数据存储。这使我们能够集中访问控制、审计日志记录、缓存逻辑等。”
Kovrin 接着解释说，如果数据库表的某个子集“与数据集的其余部分没有或很少连接，则这是一个强烈的信号，表明该组件可以被隔离到单独的 API 或单独的服务中”。
Lead Honestly 的联合创始人 Darby Frey 与此的观点相呼应：“每个服务都应该有自己的表并且永远不应该共享数据库表。”
#2：数据库表数量最小化
微服务的理想尺寸应该足够小，但不能太小。每个服务的数据库表的数量也是如此。
Scaylr 的工程主管 Steven Czerwinski 在接受采访时解释说 Scaylr 的***选择是“一个或两个服务的数据库表。”
SparkPost 的 Chris McFadden 表示同意：“我们有一个 suppression 微服务，它处理、跟踪数以百万计和数十亿围绕 suppression 的条目，但它们都非常专注于围绕 suppression，所以实际上只有一个或两个表。其他服务也是如此，比如 webhooks。
#3：考虑有状态和无状态
在设计微服务时，您需要问问自己它是否需要访问数据库，或者它是否是处理 TB 级数据 (如电子邮件或日志) 的无状态服务。
Algolia 的 CTO Julien Lemoine 解释说：“我们通过定义服务的输入和输出来定义服务的边界。有时服务是网络 API，但它也可能是使用文件并在数据库中生成记录的进程 (这就是我们的日志处理服务)。”
事先要明确是否有状态，这将引导一个更好的服务设计。
#4：考虑数据可用性需求
在设计微服务时，请记住哪些服务将依赖于此新服务，以及在该数据不可用时的整个系统的影响。考虑到这一点，您可以正确地设计此服务的数据备份和恢复系统。
Steven Czerwinski 提到，在 Scaylr 由于关键客户行空间映射数据的重要性，它将以不同的方式复制和分离。
相比之下，他补充说，“每个分片信息，都在自己的小分区里。如果部分客户群体因为没有可用日志而停止服务那很糟糕，但它只影响 5% 的客户，而不是100% 的客户。”
#5：单一的真实来源
设计服务，使其成为系统中某些内容的唯一真实来源。
例如，当您从电子商务网站订购内容时，则会生成订单 ID，其他服务可以使用此订单 ID 来查询订单服务，以获取有关订单的完整信息。使用 发布/订阅模式，在服务之间传递的数据应该是订单 ID ，而不是订单本身的属性信息。只有订单服务具有订单的完整信息，并且是给定订单信息的唯一真实来源。
大型团队的注意事项
考虑到上面列出的五个注意事项，较大的团队应了解其组织结构对微服务边界的影响。
对于较大的组织，整个团队可以专门拥有服务，在确定服务边界时，组织性就会发挥作用。还有两个需要考虑的因素：独立的发布计划和不同的正常运行时间的重要性。
Cloud66. 的 CEO Khash Sajadi 说：“我们所看到的微服务最成功的实现要么基于类似领域驱动设计这样的软件设计原则 (如面向服务的体系结构)，要么基于反映组织方法的设计原则。”
“所以 (对于) 支付团队” Sajadi 说，“他们有支付服务或信用卡验证服务，这就是他们向外界提供的服务。所以这不一定是关于软件的。这主要是关于为外界提供更多服务的业务单位。”
双披萨原理
Amazon 是一个拥有多个团队的大型组织的***示例。正如在一篇发表于 API Evangelist 的文章中所提到的，Jeff Bezos 向所有员工发布一项要求，告知他们公司内的每个团队都必须通过 API 进行沟通。任何不这样做的人都会被解雇。
这样，所有数据和功能都通过该接口公开。Bezos 还设法让每个团队解耦，定义他们的资源，并通过 API 提供。Amazon 正在从头建立一个系统。这使得公司内的每一支团队都能成为彼此的合作伙伴。
我与 Iron.io 的 CTO Travis Reeder 谈到了 Bezos 的内部倡议。
“Jeff Bezos 规定所有团队都必须构建 API 才能与其他团队进行沟通，” Reeder 说。“他也是提出‘双披萨’规则的人：一支团队不应该比两个比萨饼能养活的大。”
“我认为这里也可以适用同样的方法：无论一个小型团队是否能够开发、管理和富有成效。如果它开始变得笨重或开始变慢，它可能变得太大了。” Reeder 告诉我。
***注意事项: 您的服务是否具有合适的大小和正确的定义？
在微服务系统的测试和实施阶段，有一些指标需要记住。
指标 #1: 服务之间是否存在过度依赖？
如果两个服务不断地相互回调，那么这就是强烈的耦合信号，也是它们可能更好地合并为一个服务的信号。
回到 Chris McFadden 的例子， 他有两个 API 服务，帐户服务和用户服务不断地相互通信， McFadden 提出了一个合并服务的想法，并决定将其称为 “账户用户 API”。事实证明，这是一项富有成效的战略。
“我们开始做的是消除这些内部 API 之间调用的链接，” McFadden 告诉我。“这有助于简化代码。”
指标 #2: 设置服务的开销是否超过了服务独立的好处？
Darby Frey 解释说，“每个应用都需要将其日志聚合到某个位置，并需要进行监视。你需要设置它的警报。你需要有标准的操作程序，和在出现问题时的操作手册。您必须管理 SSH 对它的访问。只是为了让一个应用运行起来，就有大量的基础性工作必须存在。”
关键要点
设计微服务往往会让人感觉更像是一门艺术，而不是一门科学。对工程师来说，这可能并不顺利。有很多一般性的建议，但有时可能有点太抽象了。让我们回顾一下在设计下一组微服务时要注意的五个具体特征：
- 不与其他服务共享数据库表
- 数据库表数量最小化
- 考虑有状态和无状态
- 考虑数据可用性需求
- 单一的真实来源
下次设计一组微服务并确定服务边界时，回顾这些原则应该会使任务变得更容易。
