如何为服务网格选择入口网关
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.
在微服务架构中，应用程序将调用堆栈的刚性和稳定性换成了网络的灵活性和混乱性。 与调用堆栈无关的诸如延迟，重试，安全性和可追溯性之类的担忧已成为服务呼叫的关注点。 服务网格是一种出现的模式，可以将这些问题从编码人员的手中解放出来，使他们可以专注于编码业务解决方案。
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网关和服务网格之间有很多重叠。 本文探讨了什么是服务网格，它对您的组织有何好处，它与API网关的不同之处，并为服务网格的使用提供了建议。
建议摘要 (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.
任何构建在容器上运行的大型分布式组件化应用程序的应用程序团队都应使用服务网格来管理，保护和监视其服务。 这些应用程序内服务之间的流量是最适合服务网格的。 相反，应使用API网关来管理您的业务与合作伙伴之间或一个内部业务部门与另一个内部业务部门之间的交互。
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).
服务网格具有多种模式，但是理想的模式是在容器中运行的sidecar代理。 尽管Istio是最常见的服务网格产品，Consul，Linkerd，但服务网格Red Hat与OpenShift捆绑在一起(Istio的分支)，以及更多基于Kubernetes容器的选项。 在投资服务网格之前，您应该评估服务网格产品的前景，其成熟度，以及该行业是否已经确定了明确的赢家(例如，在容器领域发生的事，而Kubernetes赢得了事实上的行业标准)用于容器)。
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.
尽管服务网格在API管理，安全性，弹性和监视方面有很多重叠，但最好将它视为云技术，因为它与容器紧密结合在一起，并且旨在支持云原生应用程序。 请注意，通过“云原生”，我包括旨在在公共云以及私有(本地)云容器上运行的应用程序。
什么是服务网格？ (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.
从函数调用的调用堆栈转移到网络调用会带来安全性，不稳定和调试问题。 服务网格是用于处理这些问题的一组体系结构模式和支持工具。 举一个例子，一个函数调用知道被调用的函数总是可用的，而网络调用却不可用。 服务网格将通过执行对客户端应用程序透明的重试来帮助客户端端点处理此网络不稳定性。 通过将请求路由到最能处理如何路由流量的已配置策略的服务器节点，它还将帮助服务器端点。
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.
服务网格通常由两层实现：数据平面和控制平面。 数据平面充当连接的客户端和服务器端点的代理，强制执行从控制平面接收的策略，并将运行时指标报告回控制平面的监视工具。 控制平面管理服务策略和数据平面的编排。
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.
最受欢迎的数据平面是Envoy，这是由Lyft创建的开源代理，可作为云原生应用程序(包括本地私有云)的辅助工具运行。 最受欢迎的控制平台是Istio，这是由Lyft，Google和IBM联合创建的一个开源服务网格，用于将Envoy实例作为容器的辅助工具注入和管理云原生应用程序。
Below are some typical service mesh features, though not every service mesh implementation comes with all of these.
以下是一些典型的服务网格功能，尽管并非所有服务网格实现都随附所有这些功能。
流量路由 (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:
服务网格可以根据策略或配置将请求路由到服务实例。 可以对来自客户端应用程序的流量进行优先级排序，或者可以将流量选择性地路由到服务的不同版本，以支持：
- Canary release. 金丝雀释放。
- AB testing. AB测试。
- Service versioning / backwards compatibility. 服务版本控制/向后兼容。
可观察性 (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.
代理代替开发人员实现登录到每个客户端和服务的登录，而是代表每个客户端和服务记录调用。 通过这些日志，下游监视工具可以分析和报告性能和可用性。 它们还可以提供跨呼叫链的基本跟踪级别。 通过附加的编码，开发人员可以增强呼叫链分析以包括业务交易跟踪。
Some typical observability features:
一些典型的可观察性功能：
- Service graphs and dashboards showing how the services are connecting to each other (no code changes). 服务图和仪表板显示服务如何相互连接(无需更改代码)。
- Signals and alerts for latency, throughput, and error rate (no code changes). 发出信号和警报，以显示延迟，吞吐量和错误率(无代码更改)。
- Tracing how a request or business transaction travels though the mesh (minimal code changes to pass a transaction ID in headers). 跟踪请求或业务交易如何通过网格(最小代码更改为在标头中传递交易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.
代理强制的重试策略使开发人员与短暂无法使用被调用服务的情况完全隔离。 代理还可能尝试服务的备用路径或故障转移到备份服务。 例如，如果Netflix的个性化推荐服务处于脱机状态，则可能会退回到未个性化的默认推荐服务。 仅在尝试了所有这些努力之后，它才会返回错误。 开发人员可以相信，如果对服务的调用失败，则代理将尽最大努力处理通信错误。 另外，网格可以提供以最小的等待时间路由到服务实例以实现最佳性能的能力。
Examples of resilience patterns you can configure and enforce:
您可以配置和实施的弹性模式示例：
- Retry policies. 重试策略。
- Circuit breaker patterns. 断路器模式。
- Rate limiting / throttling. 速率限制/节流。
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.
由于服务网格会在网格内每个连接的两个端点上注入自身(恰好在您要注入“混沌”的位置)并提供监视混沌运行状况所需的可观察性，因此还可能有机会构建混沌工程能力测试。
安全政策 (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.
将单片应用程序拆分为许多独立的服务会大大增加其攻击面。 每个服务都是潜在的保护入口。 使用服务网格，客户端和服务器端点上的代理都可以应用策略来保护两者之间的通信。 服务网格通过不依赖开发人员将安全性正确地手动编程到每个服务中来促进一致的安全性。 代理负责身份验证，授权和加密。 结果是服务网格内的零信任安全性 。
身分识别 (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.
服务网格可以管理和维护哪些身份可以访问哪些服务，并维护谁在何时访问了什么服务的日志。 身份可以通过JWT进行验证，从而允许基于最终用户以及呼叫服务进行授权。
加密 (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.
如上所述，服务之间的通信是加密的。 控制平面提供证书管理功能，例如证书生成和证书轮换。 它将这些证书和相关的配置数据推送到数据平面。
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身份验证的支持非常强大。 双向TLS是两个端点将哪些证书可以位于连接的另一侧的白名单。 它提供身份验证和加密。
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网关的身份验证协议。 这是因为使用双向TLS，您必须手动维护证书并不时刷新它们。 如果手动维护未正确完成，这可能会导致维护麻烦和生产中断，就像Microsoft Teams曾经发生的那样 。 由于API网关仅管理连接的一个端点，因此需要进行手动维护，因此您必须与拥有另一个端点的组织进行手动协调，以刷新任何一方的证书。 相比之下，服务网格无需人工操作即可即时颁发新证书。 这是因为网格管理客户端和服务器端点，并且可以控制在运行时在连接的两端使用和预期使用哪些证书。
服务网格与API网关 (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.
尽管服务网格和API网关乍一看似乎很相似，但是当您深入研究基于微服务和API满足不同需求这一事实时，它们却有很大不同。
微服务和API服务不同的需求 (Microservices and APIs Serve Different Needs)
Microservices and APIs address two different problems, the former being more technical and the latter more business facing.
微服务和API解决了两个不同的问题，前者是技术性更高的问题，后者是业务面临的问题。
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).
微服务(或微服务 )应在有界上下文中进行通信(有关“ 有界上下文 ”，请参见域驱动的设计 )。 它们的设计是由连接组成有限上下文的组件的需求所驱动的，因此它们就像远程过程调用(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，但可能包括事件流和其他协议，例如SOAP，gRPC或GraphQL)应提供接口，使受限上下文可以暴露给外界。 理想情况下，它们的接口设计是由业务价值驱动的，而不仅仅是充当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在外部将一个有限上下文的业务价值暴露给另一个有限上下文，而微服务是构成有限上下文内部黑匣子的几个组件。 在传统体系结构中，这些组件可能是通过进程的调用堆栈进行通信的类或DLL。 在微服务架构中，它们可能成为跨网络通信的独立服务。
服务网格和API网关满足不同需求 (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.
要了解服务网格和API网关之间的区别，首先我必须定义定向流量。 东西方流量通常是指一个人的数据中心内的数据，而南北方向是指进出数据中心的流量。 在本文中，我的意思是从有界上下文的角度来看：停留在有界上下文内的流量是东西向的，而越过有界上下文的流量是南北的。
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.
服务网格旨在管理东西向的流量。 虽然API网关可以管理东西向的流量，但服务网格更适合。 这是因为服务网格在连接的两侧都有一个代理。 东西方都可以进行这种配置，因为两个端点都由同一个应用程序开发组织控制。
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.
尽管服务网格可以管理南北流量，但API网关更适合于此。 由于连接的一部分不在服务网格的控制范围之内，因此您将失去管理双方所提供的许多价值。
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.
此外，南北流量通常涉及业务合作伙伴，并且需要管理最终用户的体验。 API网关更专注于管理这种最终用户体验。 它们通常是较大的API管理解决方案的一部分，具有集成的API目录和开发人员门户，旨在将内部开发人员和外部业务合作伙伴加入其中。 API网关通常还可以通过直接按呼叫收费或通过基于协商的合同或客户购买的层来管理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.
相反，服务网格并不专注于管理服务客户端的最终用户体验。 由于服务网格旨在管理组成应用程序/边界上下文的服务，因此其所有客户端通常由拥有服务的同一IT部门构建。 因此，如果团队需要更改影响客户的微服务的界面，则他们可以更轻松地进行更改，因为影响不会扩展到一个IT领域之外。 在IT组织的同一区域中，需要帮助弄清楚如何调用服务的开发人员可以直接询问附近的队友。
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.
另一个区别是有界上下文的边缘应该是统一的。 当所有团队建立共同的实践以了解有限的上下文如何相互作用时，就具有企业价值。 对于有界上下文，共享相同的联合API管理基础结构，以给AP1客户整个企业统一的体验，并在API设计上进行协作，更为有效。
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.
由于组成团队的控制之外的外部依赖关系的网络，与组成上下文的黑匣子内部服务相比，绑定环境的接口更难更改。 例如，您获利的API可能会被多个外部客户公司调用，或者客户通信API可能会被整个企业中的多个应用程序调用。 这些API的更改需要与这些外部公司和团队进行协调。 因此，微服务架构所提供的提高敏捷性的价值在有限上下文的边缘上被削弱了，从而将自身更多地提供给专注于管理API各种最终用户的API网关。
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网关和服务网格两者是相辅相成的：处理外部流量的API网关和处理内部流量的服务网格，导致拓扑结构如下图所示。
服务网格所有权 (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.
如上图所示，您希望为单独的应用程序使用单独的服务网格集群。 否则，如果使用一个全局服务网格集群，最终将导致两个应用程序相互耦合。 EG —如果发生服务网格中断，最好影响一个应用程序而不是多个应用程序。
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.
如果您拥有同时拥有代码和基础架构的全栈跨职能团队，则您的服务网格应归于托管应用程序的团队。
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.
另一方面，如果您有集中的团队为应用程序开发团队提供支持Kubernetes和API基础结构的支持，那么哪个人应该拥有它呢？ 乍一看，服务网格似乎可以解决许多与API网关相同的问题，因此应由与API网关保持一致的团队所有。 但是，出于两个关键原因，理想情况下，它应该与Kubernetes团队保持一致。
- 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. 服务网格与Kubernetes耦合。 将您的API网关团队放到后面，仅意味着又有一个团队可以在事件发生时参与实施和生产支持。 相比之下，由于任何使用服务网格的应用程序都将运行Kubernetes，因此让您的Kubernetes基础架构团队拥有服务网格不会再增加一个团队。
- 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. 这些工具的目标各不相同。 服务网格和私有云Kubernetes保持一致，其目标是对应用程序内部进行组件化，以实现更大的敏捷性和可扩展性。 尽管API具有敏捷性，但API管理主要是关于构建API产品以驱动新的合作伙伴关系和渠道，而企业应用程序集成通常是将应用程序彼此隔离，而不是管理应用程序的内部。
何时使用服务网格 (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.”
如果您拥有具有动态，频繁更改的服务和大量东西向通信的分布式组件化体系结构(即，微服务或微服务体系结构)，则可能需要服务网格。 以下是一些有助于您做出决定的注意事项。 如果对这些问题中任何一个的回答为“是”，请评估服务网格的价值。
Environment. Does your network topology frequently change with multiple services scaling up and down?
环境。 您的网络拓扑是否会随着多个服务的放大和缩小而频繁更改？
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?
服务数量。 您有十个或更多的微服务吗？ 您是否有大量的东西向网络流量？ 是否每个点都可以扩展到五个或更多实例？
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来保护您的服务，但又不能跟上手动维护这么多服务的证书的工作？ 请注意，自动双向TLS是采用服务网格的首要原因。
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.
可观察性。 您是否需要观察服务之间的交互并通过系统跟踪业务交易？ 但是请注意，可以使用其他监视工具(AppDynamics等)来实现可观察性。 仅出于观察目的而使用服务网格的情况很少。
何时不使用服务网格 (When Not to Use a Service Mesh)
A service mesh might not bring any additional benefits in the following cases.
在以下情况下，服务网格可能不会带来任何其他好处。
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).
很少的服务。 您几乎没有服务(少于10个是一个很好的基准)，或者您的服务无法扩展到许多实例(少于5个是一个很好的基准)。
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.
可观察性。 您不需要服务之间的细粒度跟踪。 或可观察性是您唯一的需求，也许可以通过诸如AppDynamics之类的简单工具更轻松地解决。
No east-west traffic. All the communication in your application remains within a single boundary, there is no or almost internal network communication.
没有东西向交通。 应用程序中的所有通信都保持在一个边界内，没有或几乎没有内部网络通信。
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.
固定网络拓扑。 您的应用程序的网络拓扑是固定的，并且变化非常有限。 IE —类似于具有非临时VM或裸机服务器的传统网络拓扑。
Few code changes. The agility offered by microservices and a service mesh do not apply when the business needs only infrequently change an application.
很少的代码更改。 当企业仅需要很少地更改应用程序时，微服务和服务网格所提供的敏捷性就不适用。
评估服务网格 (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.
几乎所有服务网格都使用Envoy侧车作为数据平面。 他们最明显的区别是在控制平面上。 尽管大多数控制飞机都使用Istio，但与Istio的竞争仍然很多。 同样，由于Istio是开源的，因此各种基于Istio的控制平面可能会大不相同。 因此，对不同服务网格的评估应集中在控制平面的特征上，以及哪个控制平面满足您的需求，因为控制网格而不是数据计划是服务网格供应商彼此区别的方式。
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.
控制计划是声明性的吗？ 理想情况下，您要配置声明所需最终状态的文件，并让控制平面确定如何到达此状态。 不希望有的控制平面是命令性脚本，您可以在其中告诉它如何达到所需状态。
- 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. 是否允许自助服务？ 您的基础架构和运营团队应该拥有该入口，因为您不希望开发人员任意打开通往外界的端口。 但是一旦连接通过入口，它能否路由到开发人员可以管理的控制平面的自助子模块？ 没有自助服务，您的中央基础架构和运营可能会成为瓶颈，从而混淆了服务网格和微服务的目标。
结论 (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.
服务网格采用了许多并非新概念，而是以专门用于管理组成分布式组件化应用程序的微服务或微服务的方式打包它们。 它们与API网关有很多重叠，但是主要关注点不同。 服务网格管理组成应用程序或有界上下文的黑盒服务的东西向流量。 API网关管理公共接口的南北向流量，重点是管理用户与API的关系。 服务网格管理连接的两个端点，并且仅限于容器化的应用程序。 API网关仅管理连接的服务器端点，但可以对任何API甚至是整体API服务进行管理。
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.
包含分布式组件化应用程序的现代云原生架构的团队将使用服务网格来管理该架构所带来的复杂性，包括网络不可靠性，安全性，运营监控和其他问题，从而从中发现价值。
如何为服务网格选择入口网关
400
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
