运维体系 实时计算平台 从架构到组件，深挖istio如何连接、管理和保护微服务2.0？

标签：开放平台服务治理调用链

近几年我一直从事于微服务系统的设计以及实现方面的工作，属于微服务架构一线实践者。之前做过一些单体系统的微服务改造，在微服务拆分、治理等方面都有一定的经验。

本人比较特殊一点的经历是既做过 IT 领域的微服务，也做过 CT（通讯领域）的微服务，微服务架构在这两个领域的具体形态和要求是不太一样的，但其中一些思想是互通且是很有借鉴意义的。今天主要介绍一下关于微服务的最新发展动态，以及最近谷歌推出的 Istio平台架构。

今天介绍的主题包含：服务治理、服务网格、Istio架构，以及 Istio 相应的系统组成。

一、分布式计算的八个谬论

彼得多维奇多年前提出的分布式计算的八个谬论，对于开发人员来说他们往往会忽视这八条。这八条基本上都和网络相关，例如在发起一个网络请求时，会不断地做一些尝试等待，来保障消息投递的有效性。

微服务是一个更为复杂的分布式系统，之前 SOA 或者B/S，CS 架构，它的颗粒度会更粗一点，但是如果采用微服务，它的颗粒度是更细的。在马丁·富勒博客《微服务的先决条件是什么》一文中提到一条，你必须要成为“高个子”，想成为“高个子”其实并不简单，很多公司，它们都是为了成为“高个子”，做了很多框架、平台。

二、服务治理

1、微服务治理的技术点

要成为“高个子”需要对微服务进行哪些改造，这里是相关服务治理的技术点，其中只是一部分，和服务网格比较相关的技术点，包含服务发现、负载均衡、请求路由、认证与授权、可观测性，还有健康检查、容错等。目前主流的解决方案有众所周知的 Spring Cloud， Dubbo 等，这些都是提供库来把服务治理相关的内容打包，供具体的业务去调用。

2、库或框架的问题

但是库和框架会存在一些问题：

1、学习成本。多一个库对于开发人员而言，意味着要多学一些东西，并且在业务开发过程中，还会受到库或者框架的制约。

2、对业务代码的侵入性。例如用 Spring Cloud 会在代码里面加很多额外的内容，比如每个请求里面加一个注解来表达想引用服务治理的某些功能。

3、基础库的维护、升级和下线。如果是以库的方式来提升到服务里面，库的维护、升级、下线就会造成整个服务的维护、升级、下线。

4、不同语言和技术栈。在提出微服务概念时，它的一个重要好处就是可以使用不同的技术栈来开发微服务，但如果受到框架制约，只能用这个语言，这是我们比较头痛的事情，无法发挥微服务跨语言的能力。

这些问题其实是有严重程度的，从上往下越来越让开发人员觉得不舒服。理想中的服务治理方案是什么？可以先畅想一下，整个服务治理相关的东西，应该是和业务逻辑完全隔离的，并且服务和服务之间的交互是不会考虑服务治理这块内容，最好对于业务开发来说是不可见的。

这时候怎么去做呢？就引出了容器经典部署模式——Sidecar。

3、Sidecar模式

Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也没关系，那就是两个独立的进程，如果和容器使用的话，就基于容器为单位。Sidecar模式是物理隔离的，并且与语言无关。运维体系 实时计算平台因为是两个独立的东西，可以独立发布，和微服务理念一样。另外它们是部署在同一个 Host 上面，所以资源之间可以做到相互访问，并且因为在一起所以通信延迟也不会太明显。和业务无关的功能都可以放上去，形成多个 Sidecar。今天 Sidecar 主要是把一些服务治理相关的东西放在里面，做软件设计上的思想就是分离关注点。

基于 Sidecar 模式做服务治理，之后形成连接的具体状况，如图，对于服务A来说，服务A是不知道和 Sidecar 进行通信，服务A还是向服务B发消息，照常调用通信接口，但是消息可能会被 Sidecar 捕获到，然后通过Sidecar 进行转发。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-66285-1.html