微服务 边界服务_遵循这些实用原则以获取精心设计的微服务边界
微服務(wù) 邊界服務(wù)
by Jake Lumetta
杰克·盧米塔(Jake Lumetta)
遵循這些實用原則以獲取精心設(shè)計的微服務(wù)邊界 (Follow these practical principles to get well-designed microservices boundaries)
如何避免使微服務(wù)太小和緊密耦合 (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.
使用微服務(wù)開發(fā)新系統(tǒng)的核心好處之一是該體系結(jié)構(gòu)允許開發(fā)人員獨立構(gòu)建和修改單個組件。 但是，當(dāng)要盡量減少每個API之間的回調(diào)次數(shù)時，可能會出現(xiàn)問題。
Chris McFadden, VP of Engineering at SparkPost, recounted a story of microservices design pitfalls that may sound familiar to other developers.
SparkPost工程副總裁Chris McFadden講述了一個微服務(wù)設(shè)計陷阱的故事，這對其他開發(fā)人員來說可能是熟悉的。
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業(yè)務(wù)都存在的問題：他們需要提供基本服務(wù)，例如身份驗證，帳戶管理和計費。
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.
當(dāng)然，核心問題不是如何向用戶收費。 這是設(shè)計他們的用戶帳戶微服務(wù)的方法，以支持該問題域所伴隨的一切：用戶帳戶，API密鑰，身份驗證，業(yè)務(wù)帳戶，計費等。
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.
為了解決這個問題，他們創(chuàng)建了兩個微服務(wù)：一個用戶API和一個帳戶API。 Users API將處理用戶帳戶，API密鑰和身份驗證，而Accounts API將處理所有與帳單相關(guān)的邏輯。 這是很合乎邏輯的分離，但不久之后，他們發(fā)現(xiàn)了一個問題。
“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的服務(wù)，還有另一項名為帳戶API的服務(wù)。 但是問題在于，他們之間實際上有來回的幾個呼叫。 因此，您可以在帳戶中執(zhí)行某些操作，并在用戶中擁有呼叫和終結(jié)點，反之亦然，”克里斯說。
The two services were too tightly coupled.
兩種服務(wù)之間的聯(lián)系太緊密了。
“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.
“我們意識到，在大多數(shù)情況下，您確實不希望有一種服務(wù)有時以循環(huán)的方式調(diào)用另一種服務(wù)。 通常這不是一個好主意，”他解釋說。
The solution, according to McFadden, is to apply the appropriate service boundaries.
根據(jù)McFadden的說法，解決方案是應(yīng)用適當(dāng)?shù)姆?wù)邊界。
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.
但是，如何確定這些服務(wù)邊界呢？ 與域驅(qū)動設(shè)計(DDD)有時難以理解的抽象概念(微服務(wù)框架)相反，經(jīng)驗豐富的CTO的實踐經(jīng)驗為設(shè)計微服務(wù)邊界提供了更好的框架。 下面的訪談總結(jié)了這種智慧。
避免任意規(guī)則 (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.
在設(shè)計和創(chuàng)建微服務(wù)時，不要陷入使用任意規(guī)則的陷阱。 如果您閱讀了足夠的建議，您將遇到以下一些規(guī)則。 盡管吸引人，但這些不是確定微服務(wù)邊界的正確方法。
任意規(guī)則1：微服務(wù)應(yīng)具有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).
讓我們直接講一件事：微服務(wù)中有多少行代碼沒有限制。 微服務(wù)并不會因為您編寫了幾行額外的代碼而突然變成一個整體。 關(guān)鍵是要確保服務(wù)中的代碼具有較高的內(nèi)聚性(稍后會詳細(xì)介紹)。
任意規(guī)則2：將每個功能變成微服務(wù) (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.
如果您有一個函數(shù)可以根據(jù)三個輸入值進行計算，然后返回結(jié)果，那么這是微服務(wù)的理想選擇嗎？ 它應(yīng)該是自己的可單獨部署的應(yīng)用程序嗎？ 這實際上取決于功能是什么以及如何為整個系統(tǒng)服務(wù)。
其他任意規(guī)則 (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.
其他任意規(guī)則包括那些未考慮您整個上下文的規(guī)則，例如團隊的經(jīng)驗，DevOps容量，服務(wù)在做什么以及數(shù)據(jù)的可用性需求。
精心設(shè)計的服務(wù)的五個特征 (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.
如果您已經(jīng)閱讀了有關(guān)微服務(wù)的文章，那么毫無疑問，您會遇到有關(guān)如何設(shè)計良好服務(wù)的建議。 它的大部分歸結(jié)為高凝聚力和松散耦合的原理。 雖然是合理的建議，但是這些概念非常抽象。
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.
我已經(jīng)與數(shù)十位CTO進行了交談，以向他們學(xué)習(xí)他們?nèi)绾蝿澐治⒎?wù)邊界。 我在下面為您總結(jié)了一些基本特征。
特征1：設(shè)計良好的服務(wù)不會與其他服務(wù)共享數(shù)據(jù)庫表 (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的案例中看到的那樣，在設(shè)計微服務(wù)時，如果您有多個服務(wù)引用同一張表，那是一個危險信號，因為它很可能意味著您的數(shù)據(jù)庫是耦合的源頭。
It is really about how the service relates to the data, which is exactly what Oleksiy Kovrin, Head of Swiftype SRE, Elastic, told me.
實際上，這與服務(wù)與數(shù)據(jù)的關(guān)系有關(guān)，這正是Elastic Swiftype SRE負(fù)責(zé)人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.
“在開發(fā)新服務(wù)時，我們使用的主要基本原則之一是它們不應(yīng)跨越數(shù)據(jù)庫邊界。 每個服務(wù)應(yīng)依賴于其自己的基礎(chǔ)數(shù)據(jù)存儲集。 這使我們能夠集中訪問控制，審核日志記錄，緩存邏輯等等。”他說。
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繼續(xù)解釋說，如果您的數(shù)據(jù)庫表的一個子集“與其余數(shù)據(jù)集沒有連接或連接很少，則強烈表明該組件可以隔離到單獨的API或單獨的服務(wù)中。”
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的聯(lián)合創(chuàng)始人Darby Frey回應(yīng)了這種觀點：“每個服務(wù)都應(yīng)該有自己的表[并且]永遠不要共享數(shù)據(jù)庫表。”
特征2：精心設(shè)計的服務(wù)具有最少數(shù)量的數(shù)據(jù)庫表 (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.
微服務(wù)的理想大小足夠小，但不能再小。 每個服務(wù)的數(shù)據(jù)庫表數(shù)量也是如此。
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的最佳解決方案是“一個或兩個用于服務(wù)的數(shù)據(jù)庫表”。
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)用類似的方式闡述道：“我們有一個抑制微服務(wù)，它可以處理，跟蹤數(shù)以億計的抑制項，但是它們都非常集中于抑制，因此實際上只有一兩個表。 Webhooks等其他服務(wù)也是如此。”
特征3：精心設(shè)計的服務(wù)被認(rèn)為是有狀態(tài)的或無狀態(tài)的 (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.
在設(shè)計微服務(wù)時，您需要問問自己，它是否需要訪問數(shù)據(jù)庫，或者它將成為一種無狀態(tài)服務(wù)，用于處理數(shù)十億字節(jié)的數(shù)據(jù)，例如電子郵件或日志。
Be clear about this upfront and it will lead to a better-designed service.
請對此進行明確說明，這將導(dǎo)致設(shè)計更好的服務(wù)。
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解釋說：“我們通過定義服務(wù)的輸入和輸出來定義服務(wù)的邊界。 有時，服務(wù)是網(wǎng)絡(luò)API，但它也可能是消耗文件并在數(shù)據(jù)庫中產(chǎn)生記錄的過程(這是我們的日志處理服務(wù)的情況)。”
特點4：考慮到精心設(shè)計的服務(wù)的數(shù)據(jù)可用性需求 (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.
在設(shè)計微服務(wù)時，您需要牢記哪些服務(wù)將依賴于該新服務(wù)，以及如果該數(shù)據(jù)不可用將對整個系統(tǒng)產(chǎn)生什么影響。 考慮到這一點，您可以為該服務(wù)正確設(shè)計數(shù)據(jù)備份和恢復(fù)系統(tǒng)。
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交談時，他提到他們的關(guān)鍵客戶行空間映射數(shù)據(jù)由于其重要性而被復(fù)制和分離。
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.
相反，“每個分片信息位于其自己的小分區(qū)中。 如果它下降了，那真是太糟糕了，因為那部分客戶群體將無法獲得他們的日志，但這只會影響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.
要記住的最后一個特征是將服務(wù)設(shè)計為系統(tǒng)中某些事物的唯一事實來源。
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.
舉個例子，當(dāng)您從電子商務(wù)站點訂購商品時，將生成一個訂單ID。 其他服務(wù)可以使用此訂單ID查詢有關(guān)訂單的完整信息的訂單服務(wù)。 使用發(fā)布/訂閱概念，在服務(wù)之間傳遞的數(shù)據(jù)應(yīng)該是訂單ID，而不是訂單本身的屬性/信息。 僅訂單服務(wù)具有完整的信息，并且是給定訂單的唯一事實來源。
大型團隊的其他注意事項 (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.
這些準(zhǔn)則應(yīng)該很好地為所有團隊服務(wù)，但是CTO還提到了在設(shè)計微服務(wù)邊界時要考慮到較大團隊的注意事項。
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.
對于較大的組織，整個團隊可以全力以赴地?fù)碛幸豁椃?wù)，因此在確定服務(wù)邊界時必須考慮組織因素。 需要牢記兩個注意事項：獨立的發(fā)布時間表和不同的正常運行時間重要性。
“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.
“我們看到的最成功的微服務(wù)實現(xiàn)要么基于軟件設(shè)計原理，例如域驅(qū)動設(shè)計和面向服務(wù)的體系結(jié)構(gòu)，要么反映出一種組織方法，”微控制器首席執(zhí)行官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繼續(xù)說：“因此，(對于)付款團隊，他們擁有付款服務(wù)或信用卡驗證服務(wù)，這就是他們向外界提供的服務(wù)。 因此，與軟件無關(guān)。 主要是與業(yè)務(wù)部門[向外部世界提供另一項服務(wù)有關(guān)。“
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傳播者發(fā)表的一篇文章中提到的那樣，Jeff Bezos向所有員工發(fā)出了一項授權(quán)，告知他們公司內(nèi)的每個團隊都必須通過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.
這樣，所有數(shù)據(jù)和功能都通過接口公開。 貝索斯還設(shè)法使每個團隊脫鉤，定義他們的資源，并通過API使其可用。 亞馬遜從頭開始構(gòu)建一個系統(tǒng)。 這使公司內(nèi)的每個團隊都可以成為彼此的合作伙伴。
Travis Reeder, CTO of Iron.io, commented on Bezos’ internal initiative.
Iron.io的首席技術(shù)官Travis Reeder對貝索斯的內(nèi)部倡議發(fā)表了評論。
“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)要求所有團隊必須構(gòu)建API才能與其他團隊進行通信。 他也是提出“兩個比薩餅”規(guī)則的人。 他說：“一個團隊的規(guī)模不應(yīng)該超過兩個比薩餅所能提供的。”
“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.
“我認(rèn)為這也適用于此：無論小型團隊可以發(fā)展，管理和提高生產(chǎn)力。 如果它開始變得笨拙或開始變慢，則可能會變得太大，”里德告訴我。
測試和實施期間的準(zhǔn)則 (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還提供了對危險信號的洞察力，以提請您確定服務(wù)是否太小或定義不正確。
Look out for over-reliance between two services
注意兩個服務(wù)之間的過度依賴
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.
如果兩個服務(wù)不斷地相互回叫，那么這很可能表明耦合，并且表明它們最好組合成一個服務(wù)。
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服務(wù)，帳戶和用戶不斷相互通信，麥克法登想出了一種合并服務(wù)的想法，并決定將其稱為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.
“我們開始做的是消除這些鏈接(它們之間的內(nèi)部API調(diào)用)。 它有助于簡化代碼。” 麥克法登通知了我。
Does the overhead of setting up the service outweigh the benefit of having it be independent?
設(shè)置服務(wù)的開銷是否超過了使服務(wù)獨立的好處？
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解釋說：“每個應(yīng)用都需要將其日志匯總到某個地方，并且需要對其進行監(jiān)控。 您需要為此設(shè)置警報。 您需要具有標(biāo)準(zhǔn)的操作程序，并在出現(xiàn)問題時進行操作。 您必須管理對該事物的SSH訪問。 為了使應(yīng)用程序正常運行，必須具備巨大的基礎(chǔ)。”
考慮這些特征 (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.
設(shè)計微服務(wù)是藝術(shù)與科學(xué)的結(jié)合，但是在設(shè)計下一組服務(wù)邊界時，成功實現(xiàn)微服務(wù)的特征會提供一個很好的清單。
A well-designed service:
精心設(shè)計的服務(wù)：
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.
如果您喜歡這篇文章，請通過下面的鼓掌幫助傳播！ 有關(guān)此類的更多內(nèi)容，請在Twitter上關(guān)注我們并訂閱我們的博客。
Jake Lumetta is the CEO of ButterCMS, and is publishing Microservices for Startups.
杰克Lumetta是首席執(zhí)行官ButterCMS ，并發(fā)布了創(chuàng)業(yè)微服務(wù) 。
And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS.
而且，如果您想在您的網(wǎng)站上添加博客或CMS而不用弄亂Wordpress，則應(yīng)該嘗試Butter CMS 。
翻譯自: https://www.freecodecamp.org/news/follow-these-practical-principles-and-get-well-designed-microservices-boundaries-ef2deffd69e3/
微服務(wù) 邊界服務(wù)
總結(jié)
以上是生活随笔為你收集整理的微服务 边界服务_遵循这些实用原则以获取精心设计的微服务边界的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： api代理提取_了解提取API
- 下一篇： 梦到狼狗咬人是什么意思