***CTO根据五个简单的原则为精心设计的微服务提供建议。以微服务起步的团队面临的最大挑战之一是遵守金发姑娘原则（典故来自童话《金发姑娘和三只熊》）：不要太大，不要太小，不要太紧耦合。使它成为挑战的部分原因是对什么构成设计良好的微服务的困惑。数十位CTO通过访谈分享了他们的经验，阐述了精心设计的微服务的五个特征。本文将帮助指导团队设计微服务。（更多信息请查看即将出版的新书MicroservicesforStartups，LCTT译注：完整电子版可免费下载）。本文将简要介绍微服务边界和主观“规则”，以避免在没有深入了解这五个特性的情况下开始指导您的微服务设计。使用微服务开发新系统的核心优势之一是该架构允许开发人员独立构建和修改单个组件，但在最大限度地减少每个API之间的回调次数方面可能存在问题。根据SparkPost工程副总裁ChrisMcFadden的说法，解决方案是应用适当的服务边界。关于边界，与有时难以理解和抽象的领域驱动设计（DDD，一种微服务框架）相比，本文强调了与我们行业的一些顶级CTO建立的定义明确的微服务边界的实用性。原则。避免主观“规则”如果您阅读了足够多的关于设计和创建微服务的建议，您一定会遇到以下一些“规则”。虽然将它们用作创建微服务的指南很诱人，但合并这些主观规则并不是定义微服务边界的原则性思考方式。“一个微服务应该有X行代码”让我们直截了当地说：微服务中可以有多少行代码是没有限制的。一个微服务不会因为你多写了几行代码就突然变成一个单一的应用程序。关键是要确保服务中的代码具有高度内聚性（稍后会详细介绍）。“把每一个函数都变成一个微服务”如果一个函数根据三个输入值计算一些东西并返回结果，它是微服务的理想候选者吗？它应该是一个单独部署的应用程序吗？这实际上取决于功能是什么以及它如何为整个系统服务。在您的场景中，将每个功能都变成微服务可能根本没有意义。其他主观规则包括不考虑整个上下文的规则，例如团队的经验、DevOps能力、服务在做什么以及数据的可用性需求。设计良好的服务的5个特征如果您阅读过有关微服务的内容，您无疑会遇到有关设计良好的服务的建议。简单的说就是高内聚低耦合。如果您不熟悉这些概念，可以阅读很多关于这些概念的文章。虽然他们提供了合理的建议，但这些概念相当抽象。根据与经验丰富的CTO的对话，以下是在创建设计良好的微服务时要牢记的关键特征。#1：不要与其他服务共享数据库表在SparkPost的早期，ChrisMcFadden和他的团队不得不解决一个每个SaaS业务都需要面对的问题：他们需要提供基本服务，例如身份验证、帐户管理和计费。为了解决这个问题，他们创建了两个微服务：UserAPI和AccountAPI。用户API将处理用户帐户、API密钥和身份验证，而帐户API将处理所有与计费相关的逻辑。这是一个非常合乎逻辑的分离——但没过多久他们就发现了问题。McFadden解释说，“我们有一个名为‘UsersAPI’的服务，还有一个名为‘AccountsAPI’的服务。事实上，它们之间实际上有几个来回调用。服务，然后调用并终止于一个用户服务，反之亦然”，这两个服务耦合得太紧密了。在设计微服务时，如果您有多个服务引用同一个表，这是一个危险信号，因为它可能意味着您的数据库是耦合源。这实际上是关于服务与数据的关系，这正是SwiftypeSRE，Elastic负责人OleksiyKovrin告诉我的。他说，“我们在开发新服务时使用的主要基本原则之一是它们不应该跨越数据库边界。每个服务都应该依赖于它自己的一组底层数据存储。这使我们能够集中访问控制、审计日志、缓存逻辑等等。”Kovrin继续解释说，如果数据库表的某个子集“与数据集的其余部分没有或只有很少的联系，这是一个强烈的信号，表明该组件可以隔离到一个单独的API或一个单独的服务中”。LeadHonestly的联合创始人DarbyFrey回应了这种观点：“每项服务都应该有自己的表，数据库表永远不应该共享。”#2：尽量减少数据库表的数量微服务的理想大小应该足够小，但又不能太小。每个服务的数据库表数量也是如此。Scaylr的工程总监StevenCzerwinski在接受采访时解释说，Scaylr的最佳选择是“一个或两个服务的数据库表”。SparkPost的ChrisMcFadden对此表示赞同：“我们有一个处理、跟踪数据的抑制微服务。围绕抑制有数百万和数十亿个条目，但它们都非常专注于抑制，所以实际上只有一两个表。其他表也是如此。#3：考虑有状态与无状态在设计微服务时，您需要问自己它是否需要访问数据库，或者它是否是处理TB级数据（例如电子邮件或日志）的无状态服务。Algolia的CTOJulienLemoine解释说：“我们定义服务的输入和输出来定义服务的边界。有时该服务是一个WebAPI，但它也可以是一个使用文件并在数据库中生成记录的进程（这就是我们的日志处理服务）。“预先清楚是否有状态，这将导致更好的服务设计。#4：考虑数据可用性要求在设计微服务时，请记住哪些服务将依赖于这个新服务，以及当它发生时会发生什么dataisnotavailable.system-wideimpact.考虑到这一点，你可以为这个服务适当地设计你的数据备份和恢复系统。StevenCzerwinski提到在Scaylr中由于关键客户行空间映射数据的重要性，将是不同的复制和分离。相比之下，他补充说，“每个分片信息都在它自己的小分区中。如果你的一部分客户群因为没有可用的日志而宕机是很糟糕的，但这只会影响你5%的客户，而不是100%.#5:单一真实来源设计服务，使它们成为系统中某些内容的唯一真实来源。例如，当您从电子商务网站订购商品时，会生成一个订单ID，该ID可以是被其他人使用查询订单服务以获取有关订单的完整信息的服务。使用发布/订阅模式，服务之间传递的数据应该是订单ID，而不是订单本身的属性信息。只有订单服务拥有关于订单的完整信息，并且是给定订单信息的唯一真实来源。大型团队的注意事项考虑到上面列出的五个注意事项，大型团队应该了解其组织结构对微服务边界的影响。对于较大的组织，整个团队可以独占服务，并且组织在定义服务边界时发挥作用。还有两个因素需要考虑：单独的发布时间表和不同正常运行时间的重要性。Cloud66首席执行官KhashSajadi表示：“我们所见过的最成功的微服务实施要么基于领域驱动设计（例如面向服务的架构）等软件设计原则，要么基于反映组织方法的设计原则。”“所以（对于）支付团队，”Sajadi说，“他们有支付服务或信用卡验证服务，这就是他们向外界提供的。所以这不一定与软件有关。主要是向外界提供更多服务世界业务部门。”Two-PizzaPrincipleAmazon是大型组织和多个团队的一个很好的例子。正如APIEvangelist的一篇文章中提到的，JeffBezos向所有员工发出了要求，即公司中的每个团队都必须通过API进行沟通。任何不这样做的人'将被解雇。这样，所有数据和功能都通过此接口公开。贝索斯还设法解耦每个团队，定义他们的资源，并通过API提供它们。亚马逊正在从头开始构建一个系统。这使得公司内的每个团队都成为彼此的合作伙伴。我与Iron.io的CTOTravisReeder谈到了贝索斯的内部举措。“杰夫贝索斯要求所有团队都必须构建API以与其他团队沟通，”里德说。“他是还有那个提出“两个披萨”规则的人：一个团队的规模不应该超过两个披萨可以养活的程度。”富有成效。如果它开始变大或开始变慢，它可能变得太大了，”里德告诉我。***注意：您的服务大小和定义是否正确？在微服务系统的测试和实施阶段，需要牢记一些指标。指标#1：服务之间是否存在过度依赖？如果两个服务不断地相互回调，那么这是一个强烈的耦合信号，也是一个信号，表明它们可能会更好地合并到一个服务中。回到ChrisMcFadden的例子，他有两个API服务，AccountService和UserService不断地相互对话，McFadden想出了合并服务的想法，并决定将其称为“AccountUserAPI”。事实证明这是一个卓有成效的策略。“我们开始做的是断开这些内部API之间的调用，”McFadden告诉我。“它有助于简化代码。”指标#2：设置服务的开销是否超过了服务独立性带来的好处？DarbyFrey解释说，“每个应用程序都需要在某个地方聚合它的日志，并且需要对其进行监控。你需要在上面设置警报。你需要有标准的操作程序和剧本，以防出现问题。你可以通过SSH访问它必须得到管理。为了让应用程序运行，必须做大量的基础工作。”要点设计微服务通常更像是一门艺术，而不是一门科学。对于工程师来说，这可能不会很顺利。有很多一般性建议，但有时可能有点过于抽象。让我们回顾一下在设计下一组微服务时要注意的五个具体特征：不要与其他服务共享数据库表尽量减少数据库表的数量考虑有状态和无状态考虑数据可用性要求单一事实来源下次设计一个分组微服务时和确定服务边界，审查这些原则应该使任务更容易。
