遵循这些实用原则来获得设计良好的微服务边界
避免任意规则
在设计和创建微服务时，不要陷入使用任意规则的陷阱。如果你阅读了足够的建议，你会遇到下面的一些规则。虽然吸引人，但这些不是确定微服务边界的正确方法。
任意规则＃1：微服务应该有X行代码
让我们来看一件事：对微服务中有多少行代码没有限制。微服务不会因为你写了几行额外的代码而突然变成巨石。关键是确保服务中的代码具有很高的凝聚力（稍后会详细介绍）。
任意规则＃2：将每个函数变成微服务
如果你有一个函数根据三个输入值计算出某些东西，并返回一个结果，那么这对于微服务来说是不是一个好的选择？它应该是它自己的可单独部署的应用程序吗？这真的取决于功能是什么以及它如何服务于整个系统。
其他任意规则
其他任意规则包括那些不考虑整个上下文的规则，例如团队的经验，DevOps容量，服务在做什么以及数据的可用性需求。
精心设计的服务的五大特点
如果您已阅读过有关微服务的信息，毫无疑问，您会发现有关设计良好的服务的建议。其中大部分归结为高内聚和松散耦合的原理。虽然合理的建议，但这些概念非常抽象。
特性＃1：精心设计的服务不会与其他服务共享数据库表
正如我们在上面提到的Chris McFadden的案例中看到的那样，当涉及到设计一个微服务时，如果你有多个引用同一个表的服务，这是一个红旗，因为它可能意味着你的数据库是耦合的来源。
这实际上是关于服务如何与数据相关的，这正是Elastic Swiftype SRE的负责人Oleksiy Kovrin告诉我的。
“我们在开发新服务时使用的主要基本原则之一是它们不应该跨越数据库边界。每项服务都应该依靠自己的一套底层数据存储。这使我们能够集中访问控制，审计日志记录，缓存逻辑等等，“他说。
Kovyrin继续解释说，如果数据库表的一部分“与数据集的其余部分没有或很少有关系，这是一个强烈的信号，即组件可能被隔离到单独的API或单独的服务中。”
Lead Honestly的联合创始人Darby Frey回应道：“每个服务都应该有自己的表格，并且不应该共享数据库表格。”
特点＃2：精心设计的服务拥有最少量的数据库表
微服务的理想大小足够小，但不小。每个服务的数据库表的数量也是一样。
Scaylr的工程负责人Steven Czerwinski在接受采访时向我解释说，Scaylr的甜蜜点是“一个服务的一个或两个数据库表”。
Chris McFadden以类似的口吻阐述道：“我们有一个抑制微服务，它可以处理和追踪几百万和几十亿条关于抑制的条目，但它们都集中在压制的周围，所以实际上只有一两个表。webhooks等其他服务也是如此。“
特点＃3：精心设计的服务在思想上是有状态或无状态的
在设计你的微服务时，你需要问自己是否需要访问数据库，或者它将成为一个无状态的服务，处理TB数据如电子邮件或日志。
要清楚这个前沿，它会导致更好的设计服务。
Algolia的Julien Lemoine解释说：“我们通过定义服务的输入和输出来定义服务的界限。有时服务是网络API，但它也可能是一个消耗文件并在数据库中生成记录的进程（这是我们的日志处理服务的情况）。“
特点＃4：精心设计的服务的数据可用性需求被考虑在内
在设计微服务时，您需要记住哪些服务将依赖于这项新服务，以及如果数据不可用，对系统的影响是什么。考虑到这一点，您可以为此服务正确设计数据备份和恢复系统。
当与Steven Czerwinski谈话时，他提到他们的关键客户行空间映射数据由于其重要性而以不同方式复制和分离。
相比之下，“每片碎片信息，这是在它自己的小分区。它很糟糕，因为这部分客户没有可用的原木，但它只影响5％的客户，而不是100％的客户，“Czerwinski解释说。
特点＃5：唯一真理来源
要牢记的最后一个特点是设计一个服务，使其成为系统中某件事情的唯一真理来源。
举例来说，当您从电子商务网站订购某物品时，会生成订单ID。此订单ID可供其他服务用于查询订单服务以获取有关订单的完整信息。使用pub / sub概念，在服务之间传递的数据应该是订单ID，而不是订单本身的属性/信息。只有订单服务具有完整的信息，并且是给定订单的唯一真实来源。
对较大团队的其他考虑
这些指导方针应该能够很好地为所有团队服务，但CTO也提到了大型团队在设计微服务边界时需要考虑的因素。
对于整个团队可以致力于拥有服务的大型组织而言，在确定服务边界时，组织考虑将发挥作用。有两点需要注意：独立发布时间表和不同的正常运行时间重要性。
“我们所见过的微服务最成功的实现要么基于软件设计原则，如域驱动设计，例如面向服务的体系结构，要么反映组织方法的原则，”Khash Sajadi，首席执行官Cloud66。
“所以对于支付团队来说，”Sajadi继续说道，“他们有支付服务或信用卡验证服务，这是他们向外界提供的服务。所以它不一定就是软件。这主要是关于向外界提供更多服务的业务部门。“
亚马逊是拥有多个团队的大型组织的完美典范。正如在API推荐人发表的一篇文章中提到的，Jeff Bezos向所有员工发布了一份授权，通知他们公司内的每个团队都必须通过API进行沟通。任何不会被解雇的人。
这样，所有的数据和功能都通过接口暴露出来。贝索斯还设法让每个团队解耦，定义他们的资源，并通过API使其可用。亚马逊从头开始建立一个系统。这可以让公司内的每个团队成为彼此的合作伙伴。
Iron.io首席技术官Travis Reeder评论了贝索斯的内部倡议。
“Jeff Bezos强制所有团队都必须构建API来与其他团队进行沟通。他也是提出'两个披萨'规则的人; 一个团队不应大于两个比萨饼可以吃的东西，“他说。
“我认为这同样适用于此：无论小团队能够发展，管理和生产。如果它开始变得笨拙或开始变慢，它可能变得太大，“Reeder告诉我。
测试和实施过程中的准则
首席技术官还提供了有关红旗的注意事项，以提醒注意确定服务是否太小或未正确定义。
注意两种服务之间的过度依赖
如果两个服务不断地互相呼叫，那么这是一个强烈的耦合指示和一个信号，他们可能会更好地合并成一个服务。
回过头来，Chris McFadden在本章开头分享了他的两个API服务，账户和用户，他们不断地相互沟通，McFadden想出了一个合并服务的想法，并决定称其为Accuser的API 。这原来是一个富有成效的策略：
“我们开始做的是消除它们之间的这些内部API调用的链接。这有助于简化代码。“McFadden告诉我。
建立服务的开销是否超过了独立的好处？
Darby Frey解释说：“每个应用程序需要将其日志汇总到某处并需要进行监控。您需要设置警报。你需要有标准的操作程序，并在事情中断时运行。你必须管理SSH的访问权限。为了让应用程序正常运行，必须有一个巨大的基础。“
考虑这些特征
设计微服务是艺术和科学的结合，但微服务的成功实现的特点在设计下一组服务边界时提供了一个很好的清单。
精心设计的服务：
不与其他服务共享数据库表
拥有最少量的数据库表
是深思熟虑的有状态或无状态
它的数据可用性需求是否可以解释？
唯一真理来源