我最近开始谈论集成的发展和服务网格的采用，特别是Istio。 自从我于2017年1月首次听说Istio以来，我一直感到非常兴奋。 实际上，我对这一新技术浪潮感到很兴奋，这有助于使微服务和云原生架构成为组织的可能性。 也许您可以告诉我，因为我已经写了很多有关它（请关注最新的@christianposta ：
- 微服务最难的部分：调用服务
- 使用Envoy Sidecar代理的微服务模式：系列
- http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/
- 将Envoy和Istio Circuit与Netflix OSS Hystrix进行比较
- Istio的流量屏蔽：降低代码发布的风险
- 具有Istio服务网格的微服务的高级流量共享模式
- 服务网格如何帮助微服务安全
Istio建立在容器和Kubernetes的一些目标之上：提供有价值的分布式系统模式作为与语言无关的习惯用法。 例如，Kubernetes通过执行启动/停止，运行状况检查，缩放/自动缩放等操作来管理整个机器队列中的容器，而不管容器中实际运行的是什么。 同样，Istio可以通过在应用程序容器的外部透明地应用可靠性，安全性，策略和流量方面的挑战。
随着2018年7月31日Istio 1.0的发布 ，我们看到Istio的使用和采用量出现了大幅增长。 我一直看到的一个问题是“如果Istio为我提供可靠性，我是否需要担心它在我的应用程序中的地位？”
答案是：abso-freakin-lutely :)
差不多一年前 ，我写了一篇文章，其中包含这种区别，但还不够有力。 这篇文章是我试图纠正这个问题的尝试，并且建立在前面提到的演讲的基础上。
因此，仅设置一些背景即可：Istio提供了应用程序网络的“可靠性”功能，例如
- 自动重试
- 重试配额/预算
- 连接超时
- 请求超时
- 客户端负载平衡
- 断路
- 舱壁
这些功能在处理分布式系统时至关重要。 网络是不可靠的，并且破坏了我们整体中存在的许多不错的安全假设/抽象。 我们被迫解决这些问题，或者遭受无法预测的系统范围的中断。
退后一步
更大的问题实际上是使应用程序相互通信以解决某些业务功能 。 这就是为什么我们最终编写软件以提供某种商业价值的原因。 该软件使用了业务领域中的结构，例如“客户”，“购物车”，“帐户”等。我们从“领域驱动设计 ”中看到，每种服务对这些概念的理解可能略有不同 。
这些概念指定不当，业务限制较大（例如，客户通过名称和电子邮件进行唯一标识，或者客户只能拥有一种Checking帐户等），以及不可靠的网络连接和总体不可预测的基础架构（使用假设事情会并且将会失败！）使正确构建事物变得非常困难。
端到端的正确性和安全性
但是，事实仍然是，就构建正确和安全的应用程序而言，这样做的责任就变成了应用程序（以及所有支持该应用程序的人）的责任 。 我们可以尝试将较低级别的可靠性构建到系统的组件中以进行性能或优化，但是总体责任仍然在于应用程序。 1984年，Saltzer，Reed和Clark在“系统设计的端到端参数”中涵盖了该原理。
只有在站在通信系统端点的应用程序的知识和帮助下，所讨论的功能才能完全正确地实现。
在此，“功能”是诸如“预订”或“向购物车中添加商品”之类的应用程序要求之一。 这种功能不能推广到通信系统或其组件/基础结构（此处的“通信系统”是指网络，中间件，以及为应用程序提供工作基础的任何东西）：
因此，不可能将所质疑的功能提供为通信系统本身的特征。
但是，我们可以对通信系统进行处理以使其部分可靠，并通常帮助完成更高阶的应用程序要求。 我们做这些事情是为了优化区域，因此应用程序不必太担心它，但这不是应用程序可以忽略的事情：
有时，通信系统提供的功能的不完整版本可能会有助于提高性能
例如，在Saltzer论文中，他们使用了将文件从应用程序A传输到应用程序B的示例： 
我们需要做什么（安全）以确保文件完好无损（正确）？ 在图中的任何点都可能会失败：1）存储机制可能具有失败的扇区/转置位/损坏，因此，当应用程序A读取文件时，它正在读取错误的文件； 2）应用程序可能存在错误，无法将文件读入内存或将其发送出去； 3）网络可能会混合字节顺序，文件的重复部分等。我们可以进行一些优化，例如使用更可靠的传输方式（例如TCP或消息队列），但是TCP不知道“传递”的含义。正确地保存文件”，因此我们最好的期望至少是当我们将内容放到网络上时，它们才能可靠地交付。
为了获得完全的端到端正确性，我们可能需要使用类似文件校验和的方法，该文件在初始写入时与文件一起存储，然后让B在接收文件时验证校验和。 但是，我们选择验证传输是否正确（实现细节），应用程序负责确定解决方案并正确解决问题，而不是TCP或消息队列。
出现的典型模式是什么
为了解决分布式应用程序中应用程序的正确性和安全性，我们可以使用一些模式。 前面我们提到了Istio为我们提供的一些可靠性模式，但并不是唯一的。 通常，可以使用两类模式来正确，安全地帮助构建应用程序，并且两者都是相关的。 我将这些类称为“应用程序集成”和“应用程序网络”。 两者都是应用程序的责任。 让我们来看看：
应用整合
这些模式以以下形式出现：
- 呼叫排序，多播和编排
- 汇总响应，转换消息语义，拆分消息等
- 原子性，一致性问题，传奇模式
- 反腐败层，适配器，边界转换
- 邮件重试，重复数据删除/幂等
- 邮件重新排序
- 快取
- 消息级路由
- 重试，超时
- 后端/旧版系统集成
使用“将商品添加到购物车中”的简单示例，我们可以说明以下概念：
当用户单击“添加到购物车”时，他们希望看到添加到其购物车中的商品。 在系统中，这可能涉及协调对推荐引擎的呼叫/呼叫顺序（嘿，我们将其添加到购物车，想知道是否可以计算出与之配套的推荐报价），库存服务以及其他实际调用之前的服务。插入购物车的服务。 我们需要能够将消息转换到不同的后端，处理失败（并回退我们发起的任何更改），并且在每一项服务中我们都需要能够处理重复项。 如果由于某种原因通话最终变慢并且用户再次单击“添加到购物车”怎么办？ 没有任何可靠的基础架构可以使我们免于这样做。 我们需要在应用程序中检测并实现重复检查/幂等服务。
应用网络
这些模式的形式为：
- 自动重试
- 重试配额/预算
- 连接超时
- 请求超时
- 客户端负载平衡
- 断路
- 舱壁
还有处理通过网络通信的应用程序的其他复杂问题：
- 金丝雀推出
- 交通路线
- 指标收集
- 分布式跟踪
- 交通阴影
- 故障注入
- 健康检查
- 安全
- 组织方针
我们如何使用这些模式？
过去，我们试图将应用程序责任的这些领域混合在一起。 我们会做一些事情，例如将所有内容都推到集中的基础架构中，该基础架构基本上可以100％可用（应用程序网络+应用程序集成）。 我们将应用程序关注点放到了这种集中化的基础架构中（这应该使我们更加敏捷），但是在快速更改应用程序时遇到了瓶颈和僵化。 这些动态体现在我们实施企业服务总线的方式中：
另外，我认为大型云（Netflix，Amazon，Twitter等）认识到了这些模式的“应用程序责任”方面，并将应用程序网络代码混合到了应用程序中。 想想Netflix OSS之类的事情，我们拥有用于断路，客户端负载平衡，服务发现等的不同库。
如您所知，围绕应用程序网络的Netflix OSS库非常注重Java。 随着组织开始采用Netflix OSS和诸如spring-cloud-netflix之类的衍生产品时，他们遇到了这样的事实，即一旦您开始添加其他语言，就无法操作像这样的体系结构。 Netflix具有成熟度和自动化程度来实现这一目标，其他组织则不是Netflix。 尝试操作可解决应用程序网络问题的应用程序库和框架时的一些问题：
- 每种语言/框架都有自己的解决方案
- 实现不会完全相同； 他们会有所不同，有所不同，有时是错误的
- 您如何管理，更新，修补这些库？ 即生命周期管理
- 这些库混淆了应用程序的逻辑
- 对正确实施基础知识的开发人员非常信任
Istio和服务网格通常旨在解决应用程序网络类问题。 将这些问题的解决方案移至服务网格是可操作性的优化 。 这并不意味着它不再是应用程序的责任，而是意味着这些功能的实现存在于流程之外，必须进行配置。
通过这样做，我们可以通过执行以下操作来优化可操作性：
- 这些功能随处可见的一种实现
- 一致的功能
- 正确的功能
- 应用程序操作员和应用程序开发人员均可编程
Istio和服务网格不允许您将责任转移给基础架构，它们只是增加了一定程度的可靠性并针对可操作性进行了优化。 就像在端到端参数中一样，TCP不允许您分担应用程序的责任。
Istio帮助解决问题的应用程序网络类，但是探针的应用程序集成类又是什么？ 幸运的是，对于开发人员来说，有无数的框架可以帮助解决应用程序集成方面的问题。 对于Java开发人员来说，我最喜欢的是Apache Camel ，它提供了编写正确和安全的应用程序所需的许多内容，包括：
- 呼叫排序，多播和编排
- []汇总响应，转换消息语义，拆分消息等]（https://github.com/apache/camel/blob/master/camel-core/src/main/docs/eips/aggregate-eip.adoc）
- 原子性，一致性问题，传奇模式
- 反腐败层，适配器，边界转换
- []消息重试，重复数据删除/幂等]（https://github.com/apache/camel/blob/master/camel-core/src/main/docs/eips/idempotentConsumer-eip.adoc）
- 邮件重新排序
- 快取
- 消息级路由
- 重试，超时
- 后端/旧版系统集成
其他框架包括Spring Integration ，甚至还有WSO2中一种有趣的新编程语言，称为Ballerina 。 提醒您，重用现有的模式和构造非常好，尤其是当它们存在并且对于您选择的语言而言已经成熟时，但是这些模式都不要求您使用框架。
智能端点哑管怎么样
因此，关于微服务，我的一个朋友提出了一个有关微服务的简单易用的 “智能端点和转储管道”短语，以及“使基础设施更智能”如何影响这一前提的问题：
我给出的答案是：
管道仍然很笨。 我们不会通过使用服务网格将有关应用程序正确性和安全性的应用程序逻辑强制到基础架构中。 我们只是使其变得更可靠，针对操作方面进行了优化，并简化了应用程序必须实现 （不负责）的内容。 如果您不同意或有其他想法，请随时发表评论或联系Twitter @christianposta 。
如果您想了解有关Istio的更多信息，请访问http://istio.io 。
无法将应用程序安全性和正确性转移到Istio或任何服务网格已于2018年8月10日发布。
翻译自: https://www.javacodegeeks.com/2018/08/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh.html