服务网格 - 第4页

自微服务架构开始兴起已近三年多了，早期的Spring Cloud Netflix架构已经成熟，并已被Spring Cloud整合到解决通常云问题的新解决方案中，例如，

如果单纯使用kubernetes的pod部署Spring微服务，K8s的负载平衡以及代理设置和你微服务应用之间不是非常的智能衔接，。无论如何，部署新的应用程序版本pod需要更加软化的方法。以下是典型的需求：智能调拨流量，在部署新的应用程序版本容器时，您经常需要以某种比例（即

早在像Docker和Kubernetes这样的容器平台兴起之前的10年，有一个dotCloud平台，基于100多个微服务构建的平台，支持数千个以容器运行的生产应用程序，作者将分享构建和运行它时面临的挑战与经验，并讨论服务网格到底有没有用？

如果您使用Istio，可能会遇到大量503错误的问题，目前处理503问题的一般方式有点笼罩。

所有垂直行业的组织都在继续加速采用微服务。这导致容器和客户/服务通信的使用量相应爆炸式增长。事实证明，安全，大规模和可观察地管理这些通信非常具有挑战性。这在企业内部造成了越来越多的复杂性和波动性。因此，运营商和开发人员都强烈希望封装网络的复杂性并将其推入新的网络基础设施层。目前，处理这些复杂

Spring Cloud 原本来自Netflix OSS，但是目前面临服务网格竞争，以及Netflix宣布放弃Hystrix，Spring Cloud与服务网格Istio竞争中

SMI（Service Mesh Interface）是一组API，允许不同的服务网格（Service Mesh）相互操作。微软的

服务网格是一组重要的功能，可以在运营服务式架构时解决一些困难的服务到服务通信挑战。就像Kubernetes和容器有助于在一组计算机上提供一组很好的抽象来部署和运行工作负载一样，服务网络也出现了抽象网络，使运营商和开发人员能够控制请求路由，可观察性和政策执行。这提供了很多潜力。唯一的问

最近一位大牛玩K8s，发生故障了，故障现象：我已经将GKE升级到了1.13，并且Istio从1.0 升级到了1.1。然后策略policy和mixer进入崩溃循环后退，带有响应TLS握手超时和网关超时错误。像所有分布式系统一样，以特定顺序重新启动东西来

我们的行业倾向于迷恋Google，Netflix等公司的技术架构。他们已经构建了一些令人印象深刻的技术来解决罕见的扩展问题，所以这并不奇怪。但是，您的公司/系统是否需要类似的解决方案？可能不是... 对服务网格、K8S和其他原生技术的强烈抵制是合理

Istio除了支持不同服务版本之间的更多“传统”流量路由，包括可以基于各种传入请求属性，例如URL的部分，标头值，请求方法等，Istio还支持流量镜像。当您不想发布新版本并向其公开用户时，可以使用流量镜像，但您仍然希望部署它并观察其工作原理，收集遥测数据并比较新旧服务的性能和功能。<

观点收集：1. 由于Spring Cloud“默认”集成，Netflix OSS是首选解决方案，但现在我倾向于Consul / Traefik或Consul / Nginx，或者使用K8或各种云提供商的东西 2. 与Resilience4j

JHipster目前提供了一个选项，用于生成服务网格Istio架构的应用。快速介绍IstioIstio是与Kubernetes完全整合的服务网格，它的作用是管理微服务架构中服务之间的所有通信。 <

ServiceMesh everywhere，服务网格社区又添新成员：亚马逊发布基于开源Envoy代理的应用网格(App Mesh)。

Target的数据中心中运行了许多异构基础架构，为不同的工作负载提供多个不同的后端托管基础架构。其中大部分投入生产的基础架构是用于不同用例和应用程序开发和部署模式的遗留工件。比如

我们很高兴地宣布推出Istio 1.2！1.2的特色是可预测版本: 质量可预测（我们希望每个版本都是一个好的版本）以及及时发布（我们希望能够按照众所周知的时间表发布）。几乎所有使用Istio 1.0的人都注意到了，我们花了很长时间才走到1.1。太

服务架构有时是两极分化的。我们半数的行业正在尝试使用用户级TCP堆栈来降低每一盎司的延迟（提升网络性能），而另一半人则使用Ruby＆Kubernetes和覆盖网络(overlay network)来降低网络性能并将CPU使用率提高到10年前。 Se

当我在2000年初开始使用VMware ESX时，我知道这是一个非常酷的技术; 而且不仅是我，每个人都知道它有一些特别之处。但是，我还没有完全掌握这门技术的全部价值，在那一点上，我只看到了面前的“服务器整合”。当vMotion出现时，我们意识到物理已经改变了我们的服务器，我们