微服务 熔断示例_Istio作为何时不进行微服务的示例

微服务 熔断示例

在过去的五年中，我在帮助企业进行云原生之旅方面投入了大量资金。 现代化和提高团队（最终是组织）交付基于软件的技术的速度，很大程度上取决于其人员，流程和最终的技术决策。 当应用程序体系结构的顶点已成为进行更改和“更快地进行”的瓶颈（由于各种人员/流程/技术因素）时，微服务方法可能是合适的， 但这不是唯一的方法 。

微服务不是“乌托邦式应用程序体系结构”。

过去，我曾写过文章，以为我认为许多团队无法实现这一目标 ， 如何有“艰巨的部分”使之正常工作 ，甚至还提出了一些可能对您的工作有益的技术。从长远来看 。 FWIW我什至写了关于这个主题的书 。

远离微服务可能是最好的起点，尽管今天许多组织已经通过了微服务。

您已经走上了微服务的道路

如果您确实走上了微服务之路，请在无法使用微服务时对自己和组织诚实。 正确的做法可能是您产品成功的正确之举。

对什么时候不工作诚实

尽管有最好的意图，但是一旦您开始使用微服务，即使是出于正确的原因，它还是回到整体的正确选择。 如果您的假设或决策周围的环境发生了变化，那么“回到整体”是“可以的”。

在为微服务通信构建服务网格的Istio社区中 ，控制平面的实现将逐渐从微服务方法变为更加单一的方法 。 谷歌API基础架构的首席工程师和架构师路易斯·瑞安 （ Louis Ryan）在2019年KubeConNA的Istio聚会上作了回访，详细介绍了动机并在设计文档中概述了该案例 。 从Istio 1.5（预计于2020年2月中旬）开始，我们应该开始看到istiod方法的效果，其中先前分配给各种微服务部署的功能将合并为一个守护程序。

Istio用于帮助解决微服务/云架构所带来的困难的应用程序网络挑战，那么为什么Istio本身会摆脱微服务架构？ 最直接的答案是：

事实证明，微服务方法的复杂性无法实现其预期的价值或目标。 相反，它违背了这些目标。

对于Istio项目，看起来整体方法可以更好地实现这些目标。 让我们仔细看看。

Istio实现为微服务

Istio是一个开源服务网格 ，其结构类似于具有控制平面和数据平面的其他服务网格实现。 数据平面由与每个应用程序实例一起存在并位于请求路径中的代理组成。 控制平面位于请求路径之外，用于管理和控制数据平面的行为。

从历史上看，Istio的控制平面是作为可单独部署的服务实现的，该服务执行以下操作：

• Pilot –核心数据平面配置（xDS）服务器
• Galley –配置监视，验证，转发
• Injector –负责自动注入数据平面并设置引导程序
• Citadel –证书签名，秘密生成，与CA集成等
• Telemetry –一个“混合器”组件，负责将遥测汇总和联合到各个后端
• Policy –一个负责执行策略的请求路径“混合器”组件

这些服务将由一组运营商定义的配置来驱动，并进行协调以最终服务和指导数据平面。

微服务的好处

微服务可以通过减少对系统进行更改的摩擦来使组织更快地运行。 使用微服务架构，每个服务可能会独立运行（每个服务都由他们自己的团队），并且具有独立于其他人的自己的发布节奏/生命周期。 这将使开发人员和操作员可以并行移动，从而更快地移动，而无需进行锁定/同步/协调来进行更改，否则可能会减慢部署和功能更改的速度。

服务可能进一步细分的另一个原因是其使用模式和扩展属性。 举一个简单的例子，具有大量读写操作的服务可能会受益于将读写操作分离出来，因为读操作可能会占用更多的内存（可能需要更多的缓存空间才能使读取速度更快），而写操作可能会占用更多存储空间或网络。 您可以在机器/配额上优化服务的读取部分，以使其能够独立扩展（更多内存），然后在具有SSD或优化的EBS / SAN等的其他机器上使服务的写入部分。

您可能将应用拆分为服务的其他一些原因：

• 安全问题
• 域分组
• 不同的语言优化
• 服务的重要性

转到微服务架构时，第一要权衡的是复杂性。 当您从一件事（整体）变为一堆小事情（彼此进行通信（以针对特定问题进行优化））时，您会大大增加架构和运行事物所需的基础结构的复杂性。

就您意识到的好处而言，这可能是必要的权衡。 如果没有，最好评估一下您的假设并纠正过程。 这就是Istio目前正在发生的事情。

纠正过程

首先要了解的是谁在开发和操作您的服务体系结构。 在Istio社区中，项目中有不同的组成部分，可以在不同的社区工作组中看到。 另一方面，下载和操作Istio安装的角色并不那么容易构建。 实际上，到目前为止，观察到的是一个小组（甚至一个人）操作Istio控制平面。 在某些方面，如果以较大的SaaS运行，则Istio控制平面作为一组微服务将可以很好地工作，但是在目前的采用中，情况似乎并非如此。

要了解的第二件事是如何完成发布？ 服务可以独立发布吗？ 在实践中，Istio的答案在理论上是“肯定的”，事实并非如此。 当发布新版本的Istio时，您需要升级/部署所有控制面板组件。

最后，在Istio案例中，您可以问：“是否存在其他缩放变量和各个组件的安全问题不同？” 一个诚实的答案会意识到，实际上并没有。 直接从Istio设计文档中获取istiod ：

对于大多数组件而言，今天的Istio情况并非如此-控制平面成本由单个功能（服务XDS）支配。 与之相比，其他所有控制平面特征都具有边际成本，因此分离的价值很小。

为了安全起见，所有控制平面服务都具有相同的特权级别：

如今情况并非如此，因为变异Webhook，特使引导和飞行员所行使的权力在许多方面与城堡相似，因此对它们的利用几乎具有同等的损害力

正如Istiod设计文档中的潜台词所言： “复杂性是万恶之源，或：我如何学会不再担心和爱巨石” 。

istiod是整体的化身，可支持以前发行版的所有功能，并且复杂性大大降低。 请注意，组成先前控制平面的服务仍被实现为项目内的子模块（带有边界和合同等），但是操作经验得到了改善。 操作员现在需要担心运行和升级单个二进制文件还是它们的集合。

对于Istio进入单片控制平面，可以减少大量的复杂性，而这些复杂性永远不会完全得到回报：

• 仅需一项可部署服务，安装/升级变得更加容易
• 由于不再需要用于协调服务的配置，因此降低了配置复杂性
• 更容易调试问题（在一个地方还是所有地方看看）
• 提高效率/减少传输，共享缓存等的开销

有关更多详细信息，请参见Istiod设计文档 。

另外请注意： 您可以查看我在istio 1.5中出现的这个 istiod方法的演示 。 只需注意，它是在Istio的超级Alpha版本上进行演示的，因此并不是所有的效果都很好：)

结论

我很高兴看到Istio社区继续改善其可用性和可操作性特征。 对Istio控制平面进行整体部署对于该项目非常有意义。 这对您的项目有意义吗？ 如果这样做，您会考虑吗？ 您是否以一种能够确定更改方法的时间的方式来衡量微服务体系结构（及相关基础架构）的价值/复杂度比率？

如果您有想法要分享，请在Twitter上与我联系@christianposta 。 一个好的跟进职位应该是决策表或关键指标的内容，这些指标可以决定一旦决定走微服务之路等，就应该何时改变路线。 等 如果您想为此贡献自己，那就打我。

翻译自: https://www.javacodegeeks.com/2020/01/istio-as-an-example-of-when-not-to-do-microservices.html

微服务 熔断示例