如何為服務(wù)網(wǎng)格選擇入口網(wǎng)關(guān)

In a microservices architecture, apps trade the rigidity and stability of the call stack for the flexibility and chaos of the network. Concerns such as latency, outage retries, security, and traceability that were not a concern with a call stack become a concern with a service call. Service mesh is a pattern that has arisen to take these concerns out of the hands of coders so that they can stay focused on coding business solutions.

在微服務(wù)架構(gòu)中，應(yīng)用程序?qū)⒄{(diào)用堆棧的剛性和穩(wěn)定性換成了網(wǎng)絡(luò)的靈活性和混亂性。 與調(diào)用堆棧無關(guān)的諸如延遲，重試，安全性和可追溯性之類的擔(dān)憂已成為服務(wù)呼叫的關(guān)注點。 服務(wù)網(wǎng)格是一種出現(xiàn)的模式，可以將這些問題從編碼人員的手中解放出來，使他們可以專注于編碼業(yè)務(wù)解決方案。

There is much overlap between an API gateway and a service mesh. This article explores what a service mesh is, its benefits to your organization, how it differs from an API gateway, and provides recommendations for service mesh’s use.

API網(wǎng)關(guān)和服務(wù)網(wǎng)格之間有很多重疊。 本文探討了什么是服務(wù)網(wǎng)格，它對您的組織有何好處，它與API網(wǎng)關(guān)的不同之處，并為服務(wù)網(wǎng)格的使用提供了建議。

建議摘要 (Executive Summary of Recommendations)

Any application team building a large distributed componentized application running on containers should use a service mesh to manage, secure, and monitor their services. The traffic between these intra-application services is what a service mesh is best suited for. API gateways should, in contrast, be used to manage interactions between your business and your partners or between one internal business unit and another.

任何構(gòu)建在容器上運行的大型分布式組件化應(yīng)用程序的應(yīng)用程序團(tuán)隊都應(yīng)使用服務(wù)網(wǎng)格來管理，保護(hù)和監(jiān)視其服務(wù)。 這些應(yīng)用程序內(nèi)服務(wù)之間的流量是最適合服務(wù)網(wǎng)格的。 相反，應(yīng)使用API??網(wǎng)關(guān)來管理您的業(yè)務(wù)與合作伙伴之間或一個內(nèi)部業(yè)務(wù)部門與另一個內(nèi)部業(yè)務(wù)部門之間的交互。

A service mesh comes in a variety of patterns, but the ideal pattern you should utilize is a sidecar proxy running in containers. Although Istio is the most common service mesh product, Consul, Linkerd, the service mesh Red Hat bundles with OpenShift (a fork of Istio), and more are also options for Kubernetes-based containers. Before investing in a service mesh, you should evaluate the landscape of service mesh products, their maturity, and if the industry has settled on a clear winner (as, for example, happened with in the container space with Kubernetes winning the de facto industry standard for containers).

服務(wù)網(wǎng)格具有多種模式，但是理想的模式是在容器中運行的sidecar代理。 盡管Istio是最常見的服務(wù)網(wǎng)格產(chǎn)品，Consul，Linkerd，但服務(wù)網(wǎng)格Red Hat與OpenShift捆綁在一起(Istio的分支)，以及更多基于Kubernetes容器的選項。 在投資服務(wù)網(wǎng)格之前，您應(yīng)該評估服務(wù)網(wǎng)格產(chǎn)品的前景，其成熟度，以及該行業(yè)是否已經(jīng)確定了明確的贏家(例如，在容器領(lǐng)域發(fā)生的事，而Kubernetes贏得了事實上的行業(yè)標(biāo)準(zhǔn))用于容器)。

Although a service mesh overlaps heavily with API management, security, resilience, and monitoring, it is best viewed as a cloud technology since it is so intertwined with containers and is meant to support cloud-native apps. Note, by “cloud native” I include apps designed to run on public cloud and also private (on-premises) cloud containers.

盡管服務(wù)網(wǎng)格在API管理，安全性，彈性和監(jiān)視方面有很多重疊，但最好將它視為云技術(shù)，因為它與容器緊密結(jié)合在一起，并且旨在支持云原生應(yīng)用程序。 請注意，通過“云原生”，我包括旨在在公共云以及私有(本地)云容器上運行的應(yīng)用程序。

什么是服務(wù)網(wǎng)格？ (What Is a Service Mesh?)

Moving from the call stack of function invocation to a network call introduces issues with security, instability, and debugging. A service mesh is a set of architectural patterns and supporting tools for handling those concerns. For one example, a function call knows the function being called is always available whereas a network call cannot. A service mesh will help the client endpoint handle this network instability by executing retries transparent to the client app. It will also help the server endpoint by routing the request to the server node best able to handle the based on configured policies of how to route traffic.

從函數(shù)調(diào)用的調(diào)用堆棧轉(zhuǎn)移到網(wǎng)絡(luò)調(diào)用會帶來安全性，不穩(wěn)定和調(diào)試問題。 服務(wù)網(wǎng)格是用于處理這些問題的一組體系結(jié)構(gòu)模式和支持工具。 舉一個例子，一個函數(shù)調(diào)用知道被調(diào)用的函數(shù)總是可用的，而網(wǎng)絡(luò)調(diào)用卻不可用。 服務(wù)網(wǎng)格將通過執(zhí)行對客戶端應(yīng)用程序透明的重試來幫助客戶端端點處理此網(wǎng)絡(luò)不穩(wěn)定性。 通過將請求路由到最能處理如何路由流量的已配置策略的服務(wù)器節(jié)點，它還將幫助服務(wù)器端點。

A service mesh is usually implemented with two layers: a data plane and a control plane. The data plane acts as a proxy for both client and server endpoints of a connection, enforcing the policies received from the control plane and reporting back runtime metrics to the control plane’s monitoring tool. The control plane manages the service policies and orchestration of the data plane.

服務(wù)網(wǎng)格通常由兩層實現(xiàn)：數(shù)據(jù)平面和控制平面。 數(shù)據(jù)平面充當(dāng)連接的客戶端和服務(wù)器端點的代理，強(qiáng)制執(zhí)行從控制平面接收的策略，并將運行時指標(biāo)報告回控制平面的監(jiān)視工具。 控制平面管理服務(wù)策略和數(shù)據(jù)平面的編排。

Topology of a service mesh.服務(wù)網(wǎng)格的拓?fù)洹?

The most popular data plane is Envoy, an open source proxy created by Lyft that runs as a sidecar for cloud-native apps, including on-premises private cloud. The most popular control plane is Istio, an open source service mesh created jointly by Lyft, Google, and IBM to inject and manage Envoy instances into cloud-native apps as a container sidecar.

最受歡迎的數(shù)據(jù)平面是Envoy，這是由Lyft創(chuàng)建的開源代理，可作為云原生應(yīng)用程序(包括本地私有云)的輔助工具運行。 最受歡迎的控制平臺是Istio，這是由Lyft，Google和IBM聯(lián)合創(chuàng)建的一個開源服務(wù)網(wǎng)格，用于將Envoy實例作為容器的輔助工具注入和管理云原生應(yīng)用程序。

Below are some typical service mesh features, though not every service mesh implementation comes with all of these.

以下是一些典型的服務(wù)網(wǎng)格功能，盡管并非所有服務(wù)網(wǎng)格實現(xiàn)都隨附所有這些功能。

流量路由 (Traffic Routing)

A service mesh can route requests to service instances based on a policy or configuration. Traffic from a client application may be prioritized, or traffic may be selectively routed to a different version of a service in support of:

服務(wù)網(wǎng)格可以根據(jù)策略或配置將請求路由到服務(wù)實例。 可以對來自客戶端應(yīng)用程序的流量進(jìn)行優(yōu)先級排序，或者可以將流量選擇性地路由到服務(wù)的不同版本，以支持：

• Canary release.
  金絲雀釋放。
• AB testing.
  AB測試。
• Service versioning / backwards compatibility.
  服務(wù)版本控制/向后兼容。

可觀察性 (Observability)

Instead of developers implementing logging into every client and service, the proxies log calls on behalf of each client and service. From these logs, downstream monitoring tools can analyze and report on performance and availability. They can also provide a basic level of tracing across call chains. With additional coding, developers can enhance call chain analysis to include business transaction tracing.

代理代替開發(fā)人員實現(xiàn)登錄到每個客戶端和服務(wù)的登錄，而是代表每個客戶端和服務(wù)記錄調(diào)用。 通過這些日志，下游監(jiān)視工具可以分析和報告性能和可用性。 它們還可以提供跨呼叫鏈的基本跟蹤級別。 通過附加的編碼，開發(fā)人員可以增強(qiáng)呼叫鏈分析以包括業(yè)務(wù)交易跟蹤。

Some typical observability features:

一些典型的可觀察性功能：

• Service graphs and dashboards showing how the services are connecting to each other (no code changes).
  服務(wù)圖和儀表板顯示服務(wù)如何相互連接(無需更改代碼)。
• Signals and alerts for latency, throughput, and error rate (no code changes).
  發(fā)出信號和警報，以顯示延遲，吞吐量和錯誤率(無代碼更改)。
• Tracing how a request or business transaction travels though the mesh (minimal code changes to pass a transaction ID in headers).
  跟蹤請求或業(yè)務(wù)交易如何通過網(wǎng)格(最小代碼更改為在標(biāo)頭中傳遞交易ID)。

彈性 (Resilience)

Proxy-enforced retry policies completely insulate developers from scenarios where the called service is briefly unavailable. The proxy might also try an alternate path to the service or fail over to a backup service. For example, if Netflix’s personalized recommendation service is offline, it could fall back to a default recommendation service that isn’t personalized. Only after all these efforts are tried will it return an error. Developers can trust that if a call to a service fails, the proxy has done its best to handle communication errors. Additionally, the mesh may provide the ability to route to the service instance with the lowest latency for optimal performance.

代理強(qiáng)制的重試策略使開發(fā)人員與短暫無法使用被調(diào)用服務(wù)的情況完全隔離。 代理還可能嘗試服務(wù)的備用路徑或故障轉(zhuǎn)移到備份服務(wù)。 例如，如果Netflix的個性化推薦服務(wù)處于脫機(jī)狀態(tài)，則可能會退回到未個性化的默認(rèn)推薦服務(wù)。 僅在嘗試了所有這些努力之后，它才會返回錯誤。 開發(fā)人員可以相信，如果對服務(wù)的調(diào)用失敗，則代理將盡最大努力處理通信錯誤。 另外，網(wǎng)格可以提供以最小的等待時間路由到服務(wù)實例以實現(xiàn)最佳性能的能力。

Examples of resilience patterns you can configure and enforce:

您可以配置和實施的彈性模式示例：

• Retry policies.
  重試策略。
• Circuit breaker patterns.
  斷路器模式。
• Rate limiting / throttling.
  速率限制/節(jié)流。

There may also be an opportunity to build a chaos engineering capability since the service mesh injects itself on both endpoints of every connection within the mesh (exactly where you want to inject “chaos”) and provides the observability required to monitor the health of a chaos test.

由于服務(wù)網(wǎng)格會在網(wǎng)格內(nèi)每個連接的兩個端點上注入自身(恰好在您要注入“混沌”的位置)并提供監(jiān)視混沌運行狀況所需的可觀察性，因此還可能有機(jī)會構(gòu)建混沌工程能力測試。

安全政策 (Security Policies)

Breaking a monolithic application into many independent services dramatically increases its attack surface. Each service is a potential entry point to protect. With a service mesh, the proxies on both the client and server endpoints apply policies to secure communication between the two. A service mesh fosters consistent security by not depending on developers to correctly manually program security into each and every service. The proxies take care of authentication, authorization, and encryption. The result is zero trust security within the service mesh.

將單片應(yīng)用程序拆分為許多獨立的服務(wù)會大大增加其攻擊面。 每個服務(wù)都是潛在的保護(hù)入口。 使用服務(wù)網(wǎng)格，客戶端和服務(wù)器端點上的代理都可以應(yīng)用策略來保護(hù)兩者之間的通信。 服務(wù)網(wǎng)格通過不依賴開發(fā)人員將安全性正確地手動編程到每個服務(wù)中來促進(jìn)一致的安全性。 代理負(fù)責(zé)身份驗證，授權(quán)和加密。 結(jié)果是服務(wù)網(wǎng)格內(nèi)的零信任安全性 。

身分識別 (Identity)

A service mesh can manage and maintain what identities can access which services and maintain a log of who accessed what service and when. Identity can be validated by JWT, allowing authorization based on the end user as well as the calling service.

服務(wù)網(wǎng)格可以管理和維護(hù)哪些身份可以訪問哪些服務(wù)，并維護(hù)誰在何時訪問了什么服務(wù)的日志。 身份可以通過JWT進(jìn)行驗證，從而允許基于最終用戶以及呼叫服務(wù)進(jìn)行授權(quán)。

加密 (Encryption)

As noted above, communications between services is encrypted. The control plane provides certificate management functionality such as certificate generation and certificate rotation. It pushes these certificates and relatedconfiguration data to the data plane.

如上所述，服務(wù)之間的通信是加密的。 控制平面提供證書管理功能，例如證書生成和證書輪換。 它將這些證書和相關(guān)的配置數(shù)據(jù)推送到數(shù)據(jù)平面。

Support for mutual TLS authentication is very robust. Mutual TLS is where both endpoints whitelist which certificates can be on the other side of the connection. It provides both authentication and encryption.

對雙向TLS身份驗證的支持非常強(qiáng)大。 雙向TLS是兩個端點將哪些證書可以位于連接的另一側(cè)的白名單。 它提供身份驗證和加密。

Some organizations favor OAuth over mutual TLS authentication as their API gateway’s authentication protocol. This is because with mutual TLS, you must manually maintain certificates and refresh them from time to time. This can lead to maintenance headaches and production outages when manual maintenance is not done properly, as once famously happened to Microsoft Teams. Manual maintenance is required because the API gateway only manages one endpoint of the connection, and so you must perform manual coordination with the organization that owns the other endpoint in order to refresh either party’s certificate. A service mesh, in contrast, can issue new certificates on the fly without a manual human process. This is because the mesh manages both the client and server endpoints and can control what certificates are utilized and expected on both ends of the connection at runtime.

一些組織更傾向于OAuth而非相互TLS身份驗證作為其API網(wǎng)關(guān)的身份驗證協(xié)議。 這是因為使用雙向TLS，您必須手動維護(hù)證書并不時刷新它們。 如果手動維護(hù)未正確完成，這可能會導(dǎo)致維護(hù)麻煩和生產(chǎn)中斷，就像Microsoft Teams曾經(jīng)發(fā)生的那樣 。 由于API網(wǎng)關(guān)僅管理連接的一個端點，因此需要進(jìn)行手動維護(hù)，因此您必須與擁有另一個端點的組織進(jìn)行手動協(xié)調(diào)，以刷新任何一方的證書。 相比之下，服務(wù)網(wǎng)格無需人工操作即可即時頒發(fā)新證書。 這是因為網(wǎng)格管理客戶端和服務(wù)器端點，并且可以控制在運行時在連接的兩端使用和預(yù)期使用哪些證書。

服務(wù)網(wǎng)格與API網(wǎng)關(guān) (Service Mesh vs. API Gateway)

Although a service mesh and API gateway can seem similar at first, they are very different when you dig into the details stemming from the fact that microservices and APIs serve different needs.

盡管服務(wù)網(wǎng)格和API網(wǎng)關(guān)乍一看似乎很相似，但是當(dāng)您深入研究基于微服務(wù)和API滿足不同需求這一事實時，它們卻有很大不同。

微服務(wù)和API服務(wù)不同的需求 (Microservices and APIs Serve Different Needs)

Microservices and APIs address two different problems, the former being more technical and the latter more business facing.

微服務(wù)和API解決了兩個不同的問題，前者是技術(shù)性更高的問題，后者是業(yè)務(wù)面臨的問題。

• Microservices (or miniservices) should be for communication within a bounded context (see domain-driven design for “bounded context”). Their design is driven by the needs of connecting the components that compose a bounded context and thus act like remote procedural calls (RPCs).

  微服務(wù)(或微服務(wù) )應(yīng)在有界上下文中進(jìn)行通信(有關(guān)“ 有界上下文 ”，請參見域驅(qū)動的設(shè)計 )。 它們的設(shè)計是由連接組成有限上下文的組件的需求所驅(qū)動的，因此它們就像遠(yuǎn)程過程調(diào)用(RPC)一樣。

• APIs (usually REST but could include event streams and other protocols like SOAP, gRPC, or GraphQL) should provide the interfaces that a bounded context exposes to the outside world. Ideally their interface design is driven by business value, not merely acting as an RPC.
  API(通常是REST，但可能包括事件流和其他協(xié)議，例如SOAP，gRPC或GraphQL)應(yīng)提供接口，使受限上下文可以暴露給外界。 理想情況下，它們的接口設(shè)計是由業(yè)務(wù)價值驅(qū)動的，而不僅僅是充當(dāng)RPC。

Or put another way, APIs externally expose the business value of one bounded context to another whereas microservices are the several components composing the internal black box of a bounded context. In traditional architecture, these components may have been classes or DLLs communicating via the call stack of a process. In microservices architecture, they may become independent services communicating across the network.

換句話說，API在外部將一個有限上下文的業(yè)務(wù)價值暴露給另一個有限上下文，而微服務(wù)是構(gòu)成有限上下文內(nèi)部黑匣子的幾個組件。 在傳統(tǒng)體系結(jié)構(gòu)中，這些組件可能是通過進(jìn)程的調(diào)用堆棧進(jìn)行通信的類或DLL。 在微服務(wù)架構(gòu)中，它們可能成為跨網(wǎng)絡(luò)通信的獨立服務(wù)。

服務(wù)網(wǎng)格和API網(wǎng)關(guān)滿足不同需求 (Service Mesh and API Gateway Serve Different Needs)

To understand the difference between a service mesh and API gateway, first I must define directional traffic. East-west traffic typically refers to data within one’s data center while north-south refers to traffic going in and out of your data center. In this article, I mean from the perspective of a bounded context: traffic that stays within the bounded context is east-west, and traffic that crosses outside the bounded context is north-south.

要了解服務(wù)網(wǎng)格和API網(wǎng)關(guān)之間的區(qū)別，首先我必須定義定向流量。 東西方流量通常是指一個人的數(shù)據(jù)中心內(nèi)的數(shù)據(jù)，而南北方向是指進(jìn)出數(shù)據(jù)中心的流量。 在本文中，我的意思是從有界上下文的角度來看：停留在有界上下文內(nèi)的流量是東西向的，而越過有界上下文的流量是南北的。

A service mesh is meant to manage east-west traffic. While an API gateway can manage east-west traffic, a service mesh is better suited. This is because a service mesh has a proxy on both sides of the connection. Such a configuration is possible with east-west since both endpoints are controlled by the same app dev organization.

服務(wù)網(wǎng)格旨在管理東西向的流量。 雖然API網(wǎng)關(guān)可以管理東西向的流量，但服務(wù)網(wǎng)格更適合。 這是因為服務(wù)網(wǎng)格在連接的兩側(cè)都有一個代理。 東西方都可以進(jìn)行這種配置，因為兩個端點都由同一個應(yīng)用程序開發(fā)組織控制。

A service mesh manages both client and server endpoints of east-west traffic between two components of the same application (or bounded context).服務(wù)網(wǎng)格管理同一應(yīng)用程序(或有限上下文)的兩個組件之間東西向流量的客戶端和服務(wù)器端點。

Although a service mesh can manage north-south traffic, an API gateway is better suited for that. Since one part of the connection is outside the control of the service mesh, you lose much of the value it offers from managing both sides.

盡管服務(wù)網(wǎng)格可以管理南北流量，但API網(wǎng)關(guān)更適合于此。 由于連接的一部分不在服務(wù)網(wǎng)格的控制范圍之內(nèi)，因此您將失去管理雙方所提供的許多價值。

An API gateway manages the service endpoint of north-south traffic going between different applications (or between different bounded contexts).API網(wǎng)關(guān)管理在不同應(yīng)用程序之間(或在不同有界上下文之間)進(jìn)行的南北流量的服務(wù)端點。

In addition, north-south traffic usually involves business partners and requires management of the end user’s experience. An API gateway is more focused on managing this end user experience. They are typically part of a larger API management solution, with an integrated API directory and developer portal designed to onboard both internal developers and external business partners. An API gateway also often enables monetization of an API, either through direct per-call charges or by managing SLA policies based on the negotiated contract or the tier a customer purchased.

此外，南北流量通常涉及業(yè)務(wù)合作伙伴，并且需要管理最終用戶的體驗。 API網(wǎng)關(guān)更專注于管理這種最終用戶體驗。 它們通常是較大的API管理解決方案的一部分，具有集成的API目錄和開發(fā)人員門戶，旨在將內(nèi)部開發(fā)人員和外部業(yè)務(wù)合作伙伴加入其中。 API網(wǎng)關(guān)通常還可以通過直接按呼叫收費或通過基于協(xié)商的合同或客戶購買的層來管理SLA策略來使API貨幣化。

A service mesh, in contrast, is not focused on managing the end user experience of a service’s clients. Since a service mesh is intended for managing the services that compose an application / bounded context, all its clients are typically built by the same IT department that owns the service. Hence if a team needs to change the interface of a microservice that affects the clients, they can more easily make that change since the impact does not extend beyond one IT domain. Being in the same area of the IT organization, developers who need help figuring out how to call a service can simply ask a nearby teammate.

相反，服務(wù)網(wǎng)格并不專注于管理服務(wù)客戶端的最終用戶體驗。 由于服務(wù)網(wǎng)格旨在管理組成應(yīng)用程序/邊界上下文的服務(wù)，因此其所有客戶端通常由擁有服務(wù)的同一IT部門構(gòu)建。 因此，如果團(tuán)隊需要更改影響客戶的微服務(wù)的界面，則他們可以更輕松地進(jìn)行更改，因為影響不會擴(kuò)展到一個IT領(lǐng)域之外。 在IT組織的同一區(qū)域中，需要幫助弄清楚如何調(diào)用服務(wù)的開發(fā)人員可以直接詢問附近的隊友。

Another difference is that the edges of bounded contexts should be uniform. There is enterprise value when all teams establish common practices for how bounded contexts interact with each other. It is more effective for bounded contexts to share the same federated API management infrastructure to give APl customers a uniform experience across the enterprise and to collaborate on API designs.

另一個區(qū)別是有界上下文的邊緣應(yīng)該是統(tǒng)一的。 當(dāng)所有團(tuán)隊建立共同的實踐以了解有限的上下文如何相互作用時，就具有企業(yè)價值。 對于有界上下文，共享相同的聯(lián)合API管理基礎(chǔ)結(jié)構(gòu)，以給AP1客戶整個企業(yè)統(tǒng)一的體驗，并在API設(shè)計上進(jìn)行協(xié)作，更為有效。

Interfaces into a bounded context are harder to change than the black box internal services that compose it due to the web of external dependencies outside the control of the team. For example, an API you monetize may be called by several external client companies or a customer communication API may be called by several applications across your enterprise; a change to these APIs needs to be coordinated with those external companies and teams. Hence the value of increased agility offered by a microservices architecture is diminished on the edge of bounded contexts, lending itself more to an API gateway focused on managing the various end users of the APIs.

由于組成團(tuán)隊的控制之外的外部依賴關(guān)系的網(wǎng)絡(luò)，與組成上下文的黑匣子內(nèi)部服務(wù)相比，綁定環(huán)境的接口更難更改。 例如，您獲利的API可能會被多個外部客戶公司調(diào)用，或者客戶通信API可能會被整個企業(yè)中的多個應(yīng)用程序調(diào)用。 這些API的更改需要與這些外部公司和團(tuán)隊進(jìn)行協(xié)調(diào)。 因此，微服務(wù)架構(gòu)所提供的提高敏捷性的價值在有限上下文的邊緣上被削弱了，從而將自身更多地提供給專注于管理API各種最終用戶的API網(wǎng)關(guān)。

In sum, both API gateways and service meshes complement each other: API gateways handling externally facing traffic and service meshes handling internally facing traffic, resulting in a topology that might look something like the following diagram.

總而言之，API網(wǎng)關(guān)和服務(wù)網(wǎng)格兩者是相輔相成的：處理外部流量的API網(wǎng)關(guān)和處理內(nèi)部流量的服務(wù)網(wǎng)格，導(dǎo)致拓?fù)浣Y(jié)構(gòu)如下圖所示。

Topology of two API products, each composed of microservices.兩個API產(chǎn)品的拓?fù)?#xff0c;每個產(chǎn)品由微服務(wù)組成。

服務(wù)網(wǎng)格所有權(quán) (Service Mesh Ownership)

As you can see in the above diagram, you want separate service mesh clusters for separate applications. Otherwise with one global service mesh cluster, you end up with two apps becoming coupled with each other. E.G. — If a service mesh outage occurs, it is better that it affect one application rather than several.

如上圖所示，您希望為單獨的應(yīng)用程序使用單獨的服務(wù)網(wǎng)格集群。 否則，如果使用一個全局服務(wù)網(wǎng)格集群，最終將導(dǎo)致兩個應(yīng)用程序相互耦合。 EG —如果發(fā)生服務(wù)網(wǎng)格中斷，最好影響一個應(yīng)用程序而不是多個應(yīng)用程序。

If you have full stack cross functional teams that own both the code and infrastructure, your service mesh should be owned by the team that hosts the app on it.

如果您擁有同時擁有代碼和基礎(chǔ)架構(gòu)的全?？缏毮軋F(tuán)隊，則您的服務(wù)網(wǎng)格應(yīng)歸于托管應(yīng)用程序的團(tuán)隊。

On the other hand, if you have centralized teams that support Kubernetes and API infrastructure for the app dev teams, which one should own it? At first glance a service mesh seems to solve many of the same problems as an API gateway and so should be owned by the team aligned with API gateways. Yet ideally it should be aligned with the Kubernetes team for two key reasons.

另一方面，如果您有集中的團(tuán)隊為應(yīng)用程序開發(fā)團(tuán)隊提供支持Kubernetes和API基礎(chǔ)結(jié)構(gòu)的支持，那么哪個人應(yīng)該擁有它呢？ 乍一看，服務(wù)網(wǎng)格似乎可以解決許多與API網(wǎng)關(guān)相同的問題，因此應(yīng)由與API網(wǎng)關(guān)保持一致的團(tuán)隊所有。 但是，出于兩個關(guān)鍵原因，理想情況下，它應(yīng)該與Kubernetes團(tuán)隊保持一致。

• A service mesh is coupled with Kubernetes. Putting your API gateway team behind it just means yet one more team to get involved in implementation and production support during incidents. In contrast, since any app using a service mesh will be running Kubernetes, having your Kubernetes infrastructure team own the service mesh does not add yet one more team to the mix.
  服務(wù)網(wǎng)格與Kubernetes耦合。 將您的API網(wǎng)關(guān)團(tuán)隊放到后面，僅意味著又有一個團(tuán)隊可以在事件發(fā)生時參與實施和生產(chǎn)支持。 相比之下，由于任何使用服務(wù)網(wǎng)格的應(yīng)用程序都將運行Kubernetes，因此讓您的Kubernetes基礎(chǔ)架構(gòu)團(tuán)隊擁有服務(wù)網(wǎng)格不會再增加一個團(tuán)隊。
• The goals of these tools differ. Service mesh and private cloud Kubernetes are aligned in the goal of componentizing the internals of your app for greater agility and scalability. Although APIs have an agility play, API management is primarily about building API products to drive new partnerships and channels, and enterprise application integration in general is about insulating applications from each other rather than managing the internals of an application.
  這些工具的目標(biāo)各不相同。 服務(wù)網(wǎng)格和私有云Kubernetes保持一致，其目標(biāo)是對應(yīng)用程序內(nèi)部進(jìn)行組件化，以實現(xiàn)更大的敏捷性和可擴(kuò)展性。 盡管API具有敏捷性，但API管理主要是關(guān)于構(gòu)建API產(chǎn)品以驅(qū)動新的合作伙伴關(guān)系和渠道，而企業(yè)應(yīng)用程序集成通常是將應(yīng)用程序彼此隔離，而不是管理應(yīng)用程序的內(nèi)部。

何時使用服務(wù)網(wǎng)格 (When to Use a Service Mesh)

If you have a distributed componentized architecture (i.e. —a microservices or miniservices architecture) with dynamic, frequently changing services and a high volume of east-west communications, you may need a service mesh. Here are some considerations to help you decide. Evaluate the value of a service mesh if the answer to any of these questions is “yes.”

如果您擁有具有動態(tài)，頻繁更改的服務(wù)和大量東西向通信的分布式組件化體系結(jié)構(gòu)(即，微服務(wù)或微服務(wù)體系結(jié)構(gòu))，則可能需要服務(wù)網(wǎng)格。 以下是一些有助于您做出決定的注意事項。 如果對這些問題中任何一個的回答為“是”，請評估服務(wù)網(wǎng)格的價值。

• Environment. Does your network topology frequently change with multiple services scaling up and down?

  環(huán)境。 您的網(wǎng)絡(luò)拓?fù)涫欠駮S著多個服務(wù)的放大和縮小而頻繁更改？

• Code change. Is your code changing weekly or more frequently?

  代碼更改。 您的代碼每周更改一次還是更頻繁？

• Number of services. Do you have ten or more microservices? Do you have a significant amount of east-west network traffic? Does each scale to five or more instances at any point?

  服務(wù)數(shù)量。 您有十個或更多的微服務(wù)嗎？ 您是否有大量的東西向網(wǎng)絡(luò)流量？ 是否每個點都可以擴(kuò)展到五個或更多實例？

• Security. Do you need mutual TLS to secure your services, but you can’t keep up with manual maintenance of certificates for so many services? Note that automated mutual TLS is a top reason for service mesh adoption.

  安全。 您是否需要雙向TLS來保護(hù)您的服務(wù)，但又不能跟上手動維護(hù)這么多服務(wù)的證書的工作？ 請注意，自動雙向TLS是采用服務(wù)網(wǎng)格的首要原因。

• Observability. Do you need to observe the interactions between services and trace business transactions through the system? Note, though, that observability can be achieved using other monitoring tools (AppDynamics, etc.). Using a service mesh solely for observability is rare.

  可觀察性。 您是否需要觀察服務(wù)之間的交互并通過系統(tǒng)跟蹤業(yè)務(wù)交易？ 但是請注意，可以使用其他監(jiān)視工具(AppDynamics等)來實現(xiàn)可觀察性。 僅出于觀察目的而使用服務(wù)網(wǎng)格的情況很少。

何時不使用服務(wù)網(wǎng)格 (When Not to Use a Service Mesh)

A service mesh might not bring any additional benefits in the following cases.

在以下情況下，服務(wù)網(wǎng)格可能不會帶來任何其他好處。

• Few services. You have few services (less than 10 is a good benchmark) or your services don’t scale to many instances (less than five is a good benchmark).

  很少的服務(wù)。 您幾乎沒有服務(wù)(少于10個是一個很好的基準(zhǔn))，或者您的服務(wù)無法擴(kuò)展到許多實例(少于5個是一個很好的基準(zhǔn))。

• Observability. You do not need fine grained tracing between services. Or observability is your only need, perhaps can be more easily solved with simpler tools like AppDynamics.

  可觀察性。 您不需要服務(wù)之間的細(xì)粒度跟蹤。 或可觀察性是您唯一的需求，也許可以通過諸如AppDynamics之類的簡單工具更輕松地解決。

• No east-west traffic. All the communication in your application remains within a single boundary, there is no or almost internal network communication.

  沒有東西向交通。 應(yīng)用程序中的所有通信都保持在一個邊界內(nèi)，沒有或幾乎沒有內(nèi)部網(wǎng)絡(luò)通信。

• Fixed network topology. The network topology of your application is fixed and subject to very limited change. IE — Like the traditional network topology with non-ephemeral VMs or bare metal servers.

  固定網(wǎng)絡(luò)拓?fù)洹?/strong> 您的應(yīng)用程序的網(wǎng)絡(luò)拓?fù)涫枪潭ǖ?#xff0c;并且變化非常有限。 IE —類似于具有非臨時VM或裸機(jī)服務(wù)器的傳統(tǒng)網(wǎng)絡(luò)拓?fù)洹?

• Few code changes. The agility offered by microservices and a service mesh do not apply when the business needs only infrequently change an application.

  很少的代碼更改。 當(dāng)企業(yè)僅需要很少地更改應(yīng)用程序時，微服務(wù)和服務(wù)網(wǎng)格所提供的敏捷性就不適用。

評估服務(wù)網(wǎng)格 (Evaluating Service Meshes)

Almost all service meshes use an Envoy side car as the data plane. Where they have the starkest difference is in the control plane. While most control planes use Istio, there is still a lot of competition with Istio. Also, since Istio is open source, various Istio-based control planes can differ dramatically. Therefore, an evaluation of different service meshes should focus on the features of the control planes and which control planes meet your needs since the control plane, not the data plan, is how service mesh vendors differentiate from each other.

幾乎所有服務(wù)網(wǎng)格都使用Envoy側(cè)車作為數(shù)據(jù)平面。 他們最明顯的區(qū)別是在控制平面上。 盡管大多數(shù)控制飛機(jī)都使用Istio，但與Istio的競爭仍然很多。 同樣，由于Istio是開源的，因此各種基于Istio的控制平面可能會大不相同。 因此，對不同服務(wù)網(wǎng)格的評估應(yīng)集中在控制平面的特征上，以及哪個控制平面滿足您的需求，因為控制網(wǎng)格而不是數(shù)據(jù)計劃是服務(wù)網(wǎng)格供應(yīng)商彼此區(qū)別的方式。

Some considerations:

一些注意事項：

• Does the control plane provide the most value in your Cl/CI pipeline?
  控制平面是否在您的Cl / CI管道中提供了最大的價值？

• Is the control plan declarative? Ideally you want to configure files that declare your desired end state and let the control plane figure out how to get there. An undesirable control plane is imperative scripting where you tell it how to achieve your desired state.

  控制計劃是聲明性的嗎？ 理想情況下，您要配置聲明所需最終狀態(tài)的文件，并讓控制平面確定如何到達(dá)此狀態(tài)。 不希望有的控制平面是命令性腳本，您可以在其中告訴它如何達(dá)到所需狀態(tài)。

• Does it allow self-service? Your infrastructure & operations team should own the ingress since you don’t want developers arbitrarily opening up ports to the outside world. But once a connection has passed through ingress, can it route to a self-service sub-module of the control plane that developers can administer? Without self-services, your central infrastructure & operations can become a bottleneck, confounding the goal of a service mesh and microservices.
  是否允許自助服務(wù)？ 您的基礎(chǔ)架構(gòu)和運營團(tuán)隊?wèi)?yīng)該擁有該入口，因為您不希望開發(fā)人員任意打開通往外界的端口。 但是一旦連接通過入口，它能否路由到開發(fā)人員可以管理的控制平面的自助子模塊？ 沒有自助服務(wù)，您的中央基礎(chǔ)架構(gòu)和運營可能會成為瓶頸，從而混淆了服務(wù)網(wǎng)格和微服務(wù)的目標(biāo)。

結(jié)論 (Conclusion)

Service meshes take many concepts that are not new but package them in a way that is purpose built for managing the microservices or miniservices that compose a distributed componentized application. They have much overlap with API gateways but differ primarily in their focus. Service meshes manage east-west traffic of the black box services that compose an application or bounded context; API gateways manage the north-south traffic of public interfaces with a focus on managing the users’ relationship with an API. Service meshes manage both endpoints of a connection and are limited to containerized apps; API gateways manage only the server’s endpoint of a connection but can do so for any API, even monolithic API services.

服務(wù)網(wǎng)格采用了許多并非新概念，而是以專門用于管理組成分布式組件化應(yīng)用程序的微服務(wù)或微服務(wù)的方式打包它們。 它們與API網(wǎng)關(guān)有很多重疊，但是主要關(guān)注點不同。 服務(wù)網(wǎng)格管理組成應(yīng)用程序或有界上下文的黑盒服務(wù)的東西向流量。 API網(wǎng)關(guān)管理公共接口的南北向流量，重點是管理用戶與API的關(guān)系。 服務(wù)網(wǎng)格管理連接的兩個端點，并且僅限于容器化的應(yīng)用程序。 API網(wǎng)關(guān)僅管理連接的服務(wù)器端點，但可以對任何API甚至是整體API服務(wù)進(jìn)行管理。

Teams that embrace the modern cloud-native architecture of distributed componentized apps will find value using a service mesh to manage the complexities that this architecture entails, including network unreliability, security, operational monitoring, and other concerns.

包含分布式組件化應(yīng)用程序的現(xiàn)代云原生架構(gòu)的團(tuán)隊將使用服務(wù)網(wǎng)格來管理該架構(gòu)所帶來的復(fù)雜性，包括網(wǎng)絡(luò)不可靠性，安全性，運營監(jiān)控和其他問題，從而從中發(fā)現(xiàn)價值。

翻譯自: https://levelup.gitconnected.com/deciphering-the-difference-between-a-service-mesh-and-api-gateway-c57e4abec302

如何為服務(wù)網(wǎng)格選擇入口網(wǎng)關(guān)

總結(jié)

以上是生活随笔為你收集整理的如何为服务网格选择入口网关_理解服务网格和API网关之间的差异的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。