微服務 邊界服務
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/
微服務 邊界服務
函數)
)
