微服务 边界服务
by Jake Lumetta
杰克·卢米塔(Jake Lumetta)
遵循这些实用原则以获取精心设计的微服务边界 (Follow these practical principles to get well-designed microservices boundaries)
如何避免使微服务太小和紧密耦合 (How to avoid making your microservices too small and tightly coupled)
One of the core benefits of developing new systems with microservices is that the architecture allows developers to build and modify individual components independently. But problems can arise when it comes to minimizing the number of callbacks between each API.
使用微服务开发新系统的核心好处之一是该体系结构允许开发人员独立构建和修改单个组件。 但是，当要尽量减少每个API之间的回调次数时，可能会出现问题。
Chris McFadden, VP of Engineering at SparkPost, recounted a story of microservices design pitfalls that may sound familiar to other developers.
SparkPost工程副总裁Chris McFadden讲述了一个微服务设计陷阱的故事，这对其他开发人员来说可能是熟悉的。
In the early days of SparkPost, McFadden and his team had to solve a problem that every SaaS business has: they needed to provide basic services like authentication, account management, and billing.
在SparkPost成立之初，McFadden和他的团队不得不解决每个SaaS业务都存在的问题：他们需要提供基本服务，例如身份验证，帐户管理和计费。
The core problem, of course, wasn’t how to charge their users money. It was how to design their user account microservices to support everything that goes along with that problem domain: user accounts, API keys, authentication, business accounts, billing, and so on.
当然，核心问题不是如何向用户收费。 这是设计他们的用户帐户微服务的方法，以支持该问题域所伴随的一切：用户帐户，API密钥，身份验证，业务帐户，计费等。
To tackle this, they created two microservices: a Users API and an Accounts API. The Users API would handle user accounts, API keys, and authentication, and the Accounts API would handle all of the billing related logic. A very logical separation, but before long, they spotted a problem.
为了解决这个问题，他们创建了两个微服务：一个用户API和一个帐户API。 Users API将处理用户帐户，API密钥和身份验证，而Accounts API将处理所有与帐单相关的逻辑。 这是很合乎逻辑的分离，但不久之后，他们发现了一个问题。
“We had one service that was called the User API, and we had another one called the Account API. But the problem was that they were actually having several calls back and forth between them. So you would do something in accounts and have call and endpoint in users or vice versa,” Chris stated.
“我们有一项称为用户API的服务，还有另一项名为帐户API的服务。 但是问题在于，他们之间实际上有来回的几个呼叫。 因此，您可以在帐户中执行某些操作，并在用户中拥有呼叫和终结点，反之亦然，”克里斯说。
The two services were too tightly coupled.
两种服务之间的联系太紧密了。
“We realized that in most cases, you really don’t want to have one service calling another service in a sometimes circular way. That’s generally not a good idea,” he explained.
“我们意识到，在大多数情况下，您确实不希望有一种服务有时以循环的方式调用另一种服务。 通常这不是一个好主意，”他解释说。
The solution, according to McFadden, is to apply the appropriate service boundaries.
根据McFadden的说法，解决方案是应用适当的服务边界。
But how does one determine those service boundaries? In contrast to the sometimes difficult-to-grasp and abstract concept of domain driven design (DDD) — a framework for microservices — practical wisdom from experienced CTOs offers a better framework for designing microservice boundaries. That wisdom, from hours of interviews, is distilled below.
但是，如何确定这些服务边界呢？ 与域驱动设计(DDD)有时难以理解的抽象概念(微服务框架)相反，经验丰富的CTO的实践经验为设计微服务边界提供了更好的框架。 下面的访谈总结了这种智慧。
避免任意规则 (Avoid Arbitrary Rules)
When designing and creating a microservice, don’t fall into the trap of using arbitrary rules. If you read enough advice, you’ll come across some of the rules below. While appealing, these are not proper ways to determine boundaries for microservices.
在设计和创建微服务时，不要陷入使用任意规则的陷阱。 如果您阅读了足够的建议，您将遇到以下一些规则。 尽管吸引人，但这些不是确定微服务边界的正确方法。
任意规则1：微服务应具有X行代码 (Arbitrary Rule #1: A microservice should have X lines of code)
Let’s get one thing straight: there are no limitations on how many lines of code there are in a microservice. A microservice doesn’t suddenly become a monolith just because you write a few lines of extra code. The key is ensuring there is high cohesion for the code within a service (more on this later).
让我们直接讲一件事：微服务中有多少行代码没有限制。 微服务并不会因为您编写了几行额外的代码而突然变成一个整体。 关键是要确保服务中的代码具有较高的内聚性(稍后会详细介绍)。
任意规则2：将每个功能变成微服务 (Arbitrary Rule #2: Turn each function into a microservice)
If you have a function that computes something based on three input values, and returns a result, is that a good candidate for a microservice? Should it be a separately deployable application of its own? This really depends on what the function is and how it serves to the entire system.
如果您有一个函数可以根据三个输入值进行计算，然后返回结果，那么这是微服务的理想选择吗？ 它应该是自己的可单独部署的应用程序吗？ 这实际上取决于功能是什么以及如何为整个系统服务。
其他任意规则 (Other arbitrary rules)
Other arbitrary rules include those that don’t take into account your entire context such as the team’s experience, DevOps capacity, what the service is doing, and availability needs of the data.
其他任意规则包括那些未考虑您整个上下文的规则，例如团队的经验，DevOps容量，服务在做什么以及数据的可用性需求。
精心设计的服务的五个特征 (Five characteristics of a well-designed service)
If you’ve read about microservices, you’ve no doubt come across advice on what makes a well-designed service. Much of it boils down to the principle of high cohesion and loose coupling. While sound advice, these concepts are quite abstract.
如果您已经阅读了有关微服务的文章，那么毫无疑问，您会遇到有关如何设计良好服务的建议。 它的大部分归结为高凝聚力和松散耦合的原理。 虽然是合理的建议，但是这些概念非常抽象。
I’ve spoken with dozens of CTO’s on this topic to learn from them how they’ve drawn their microservice boundaries. I’ve distilled down some of the underlying characteristics for you below.
我已经与数十位CTO进行了交谈，以向他们学习他们如何划分微服务边界。 我在下面为您总结了一些基本特征。
特征1：设计良好的服务不会与其他服务共享数据库表 (Characteristic #1: A well-designed service doesn’t share database tables with another service)
As we saw in Chris McFadden’s case mentioned above, when it comes to designing a microservice if you have multiple services referencing the same table, that’s a red flag as it likely means your DB is a source of coupling.
正如我们在上面提到的Chris McFadden的案例中看到的那样，在设计微服务时，如果您有多个服务引用同一张表，那是一个危险信号，因为它很可能意味着您的数据库是耦合的源头。
It is really about how the service relates to the data, which is exactly what Oleksiy Kovrin, Head of Swiftype SRE, Elastic, told me.
实际上，这与服务与数据的关系有关，这正是Elastic Swiftype SRE负责人Oleksiy Kovrin告诉我的。
“One of the main foundational principles we use when developing new services is that they should not cross database boundaries. Each service should rely on its own set of underlying data stores. This allows us to centralize access controls, audit logging, caching logic, et cetera,” he said.
“在开发新服务时，我们使用的主要基本原则之一是它们不应跨越数据库边界。 每个服务应依赖于其自己的基础数据存储集。 这使我们能够集中访问控制，审核日志记录，缓存逻辑等等。”他说。
Kovyrin went on to explain that if a subset of your database tables, “have no or very little connections to the rest of the dataset, it is a strong signal that component could be isolated into a separate API or a separate service.”
Kovyrin继续解释说，如果您的数据库表的一个子集“与其余数据集没有连接或连接很少，则强烈表明该组件可以隔离到单独的API或单独的服务中。”
Darby Frey, co-founder of Lead Honestly, echoed this sentiment: “Each service should have its own tables [and] should never share database tables.”
Lead Honestly的联合创始人Darby Frey回应了这种观点：“每个服务都应该有自己的表[并且]永远不要共享数据库表。”
特征2：精心设计的服务具有最少数量的数据库表 (Characteristic #2: A well-designed service has a minimal amount of database tables)
The ideal size of a microservice is small enough, but no smaller. And the same goes for the number of database tables per service.
微服务的理想大小足够小，但不能再小。 每个服务的数据库表数量也是如此。
Steven Czerwinski, Head of Engineering at Scaylr, explained to me during an interview that the sweet spot for Scaylr is, “one or two database tables for a service.”
Scaylr的工程主管Steven Czerwinski在接受采访时向我解释说，Scaylr的最佳解决方案是“一个或两个用于服务的数据库表”。
Chris McFadden elaborated in a similar vein: “We have a suppression microservices, and it handles, keeps track of, millions and billions of entries around suppressions but it’s all very focused just around suppression so there’s really only one or two tables there. The same goes for other services like webhooks.”
克里斯·麦克法登(Chris McFadden)用类似的方式阐述道：“我们有一个抑制微服务，它可以处理，跟踪数以亿计的抑制项，但是它们都非常集中于抑制，因此实际上只有一两个表。 Webhooks等其他服务也是如此。”
特征3：精心设计的服务被认为是有状态的或无状态的 (Characteristic #3: A well-designed service is thoughtfully stateful or stateless)
When designing your microservice, you need to ask yourself whether it requires access to a database or it’s going to be a stateless service processing terabytes of data like emails or logs.
在设计微服务时，您需要问问自己，它是否需要访问数据库，或者它将成为一种无状态服务，用于处理数十亿字节的数据，例如电子邮件或日志。
Be clear about this upfront and it will lead to a better-designed service.
请对此进行明确说明，这将导致设计更好的服务。
Julien Lemoine of Algolia explains, “We define the boundaries of a service by defining its input and output. Sometimes a service is a network API but it can also be a process consuming files and producing records in a database (this is the case of our log processing service).”
阿尔及利亚的Julien Lemoine解释说：“我们通过定义服务的输入和输出来定义服务的边界。 有时，服务是网络API，但它也可能是消耗文件并在数据库中产生记录的过程(这是我们的日志处理服务的情况)。”
特点4：考虑到精心设计的服务的数据可用性需求 (Characteristic #4: A well-designed service’s data availability needs are accounted for)
When designing a microservice, you need to keep in mind what services will rely on this new service and what’s the system-wide impact if that data becomes unavailable. Taking that into account allows you properly design data backup and recovery systems for this service.
在设计微服务时，您需要牢记哪些服务将依赖于该新服务，以及如果该数据不可用将对整个系统产生什么影响。 考虑到这一点，您可以为该服务正确设计数据备份和恢复系统。
When speaking to Steven Czerwinski, he mentioned their critical customer row space mapping data is replicated and separated in different ways due to its importance.
在与Steven Czerwinski交谈时，他提到他们的关键客户行空间映射数据由于其重要性而被复制和分离。
In contrast, “the per shard information, that’s in its own little partition. It sucks if it goes down because that portion of the customer population is not going to have their logs available, but it’s only impacting 5 percent of the customers rather than 100 percent of the customers,” Czerwinski explained.
相反，“每个分片信息位于其自己的小分区中。 如果它下降了，那真是太糟糕了，因为那部分客户群体将无法获得他们的日志，但这只会影响5％的客户，而不是100％的客户。” Czerwinski解释说。
特点5：这是真理的单一来源 (Characteristic #5: It’s a single source of truth)
The final characteristic to keep in mind is to design a service to be the single source of truth for something in your system.
要记住的最后一个特征是将服务设计为系统中某些事物的唯一事实来源。
To give you an example, when you order something from an eCommerce site, an order ID is generated. This order ID can be used by other services to query an Order service for complete information about the order. Using the pub/sub concept, the data that is passed around between services should be the order ID, not the attributes/information of the order itself. Only the Order service has complete information and is the single source of truth for a given order.
举个例子，当您从电子商务站点订购商品时，将生成一个订单ID。 其他服务可以使用此订单ID查询有关订单的完整信息的订单服务。 使用发布/订阅概念，在服务之间传递的数据应该是订单ID，而不是订单本身的属性/信息。 仅订单服务具有完整的信息，并且是给定订单的唯一事实来源。
大型团队的其他注意事项 (Additional considerations for larger teams)
These guidelines should serve all teams well, but CTOs also mentioned considerations for larger teams to take into account when designing microservice boundaries.
这些准则应该很好地为所有团队服务，但是CTO还提到了在设计微服务边界时要考虑到较大团队的注意事项。
For larger organizations, where entire teams can be dedicated to owning a service, organizational consideration comes into play when determining service boundaries. And there are two considerations to keep in mind: independent release schedule and different uptime importance.
对于较大的组织，整个团队可以全力以赴地拥有一项服务，因此在确定服务边界时必须考虑组织因素。 需要牢记两个注意事项：独立的发布时间表和不同的正常运行时间重要性。
“The most successful implementation of microservices we’ve seen is either based on a software design principle like domain-driven design, for example, and service-oriented architecture, or the ones that reflect an organizational approach,” said Khash Sajadi, CEO of Cloud66.
“我们看到的最成功的微服务实现要么基于软件设计原理，例如域驱动设计和面向服务的体系结构，要么反映出一种组织方法，”微控制器首席执行官Khash Sajadi说云端66。
“So [for the] payments team,” Sajadi continued, “they have the payment service or credit card validation service and that’s the service they provide to the outside world. So it’s not necessarily anything about software. It’s mostly about the business unit [that] provides one more service to the outside world.”
Sajadi继续说：“因此，(对于)付款团队，他们拥有付款服务或信用卡验证服务，这就是他们向外界提供的服务。 因此，与软件无关。 主要是与业务部门[向外部世界提供另一项服务有关。“
Amazon is a perfect example of a large organization with multiple teams. As mentioned in an article published in API Evangelist, Jeff Bezos issued a mandate to all employees informing them that every team within the company had to communicate via API. Anyone who didn’t would be fired.
亚马逊是拥有多个团队的大型组织的完美典范。 正如在API传播者发表的一篇文章中提到的那样，Jeff Bezos向所有员工发出了一项授权，告知他们公司内的每个团队都必须通过API进行沟通。 任何没有的人都会被解雇。
This way, all the data and functionality was exposed through the interface. Bezos also managed to get every team to decouple, define what their resources were, and make them available through the API. Amazon was building a system from the ground up. This allows every team within the company to become a partner of one another.
这样，所有数据和功能都通过接口公开。 贝索斯还设法使每个团队脱钩，定义他们的资源，并通过API使其可用。 亚马逊从头开始构建一个系统。 这使公司内的每个团队都可以成为彼此的合作伙伴。
Travis Reeder, CTO of Iron.io, commented on Bezos’ internal initiative.
Iron.io的首席技术官Travis Reeder对贝索斯的内部倡议发表了评论。
“Jeff Bezos mandated that all teams had to build API’s to communicate with other teams. He’s also the guy who came up with the ‘two pizza’ rule; a team shouldn’t be larger than what two pizzas can feed,” he said.
“杰夫·贝佐斯(Jeff Bezos)要求所有团队必须构建API才能与其他团队进行通信。 他也是提出“两个比萨饼”规则的人。 他说：“一个团队的规模不应该超过两个比萨饼所能提供的。”
“I think the same could apply here: whatever a small team can develop, manage and be productive with. If it starts to get unwieldy or starts to slow down, it’s probably getting too big,” Reeder told me.
“我认为这也适用于此：无论小型团队可以发展，管理和提高生产力。 如果它开始变得笨拙或开始变慢，则可能会变得太大，”里德告诉我。
测试和实施期间的准则 (Guidelines during testing and implementation)
CTOs also offered insight into red flags to watch out for to determine if a service is too small or not properly defined.
CTO还提供了对危险信号的洞察力，以提请您确定服务是否太小或定义不正确。
Look out for over-reliance between two services
注意两个服务之间的过度依赖
If two services are constantly calling back to one another, then that’s a strong indication of coupling and a signal that they might be better off combined into one service.
如果两个服务不断地相互回叫，那么这很可能表明耦合，并且表明它们最好组合成一个服务。
Going back to the example Chris McFadden shared at the beginning of this chapter where he had two API services, accounts and users that were constantly communicating with one another, McFadden came up with an idea to merge the services and decided to call it the Accuser’s API. This turned out to be a fruitful strategy:
回到本章开始时克里斯·麦克法登(Chris McFadden)共享的示例，他有两个API服务，帐户和用户不断相互通信，麦克法登想出了一种合并服务的想法，并决定将其称为Accuser的API 。 事实证明这是一个富有成效的策略：
“What we started doing was eliminating these links [which were the] internal API calls between them. It’s helped simplify the code.” McFadden informed me.
“我们开始做的是消除这些链接(它们之间的内部API调用)。 它有助于简化代码。” 麦克法登通知了我。
Does the overhead of setting up the service outweigh the benefit of having it be independent?
设置服务的开销是否超过了使服务独立的好处？
Darby Frey explained, “Every app needs to have its logs aggregated somewhere and needs to be monitored. You need to set up alerting for it. You need to have standard operating procedures and run books for when things break. You have to manage SSH access to that thing. There’s a huge foundation of things that have to exist in order for an app to just run.”
Darby Frey解释说：“每个应用都需要将其日志汇总到某个地方，并且需要对其进行监控。 您需要为此设置警报。 您需要具有标准的操作程序，并在出现问题时进行操作。 您必须管理对该事物的SSH访问。 为了使应用程序正常运行，必须具备巨大的基础。”
考虑这些特征 (Consider these characteristics)
Designing microservices is a combination of art and science, but characteristics of successful implementations of microservices provide a great checklist when designing your next set of service boundaries.
设计微服务是艺术与科学的结合，但是在设计下一组服务边界时，成功实现微服务的特征会提供一个很好的清单。
A well-designed service:
精心设计的服务：
- Doesn’t share database tables with another service 不与其他服务共享数据库表
- Has a minimal amount of database tables 数据库数量最少
- Is thoughtfully stateful or stateless 周到或有状态
- Has its data availability needs accounted for 是否已考虑其数据可用性需求
- Is a single source of truth 是真理的单一来源
If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.
如果您喜欢这篇文章，请通过下面的鼓掌帮助传播！ 有关此类的更多内容，请在Twitter上关注我们并订阅我们的博客。
Jake Lumetta is the CEO of ButterCMS, and is publishing Microservices for Startups.
杰克Lumetta是首席执行官ButterCMS ，并发布了创业微服务 。
And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS.
而且，如果您想在您的网站上添加博客或CMS而不用弄乱Wordpress，则应该尝试Butter CMS 。
翻译自: https://www.freecodecamp.org/news/follow-these-practical-principles-and-get-well-designed-microservices-boundaries-ef2deffd69e3/
微服务 边界服务
函数)
)
