近几年我一直从事于微服务系统的设计以及实现方面的工作，属于微服务架构一线实践者。之前做过一些单体系统的微服务改造，在微服务拆分、治理等方面都有一定的经验。
本人比较特殊一点的经历是既做过IT领域的微服务，也做过CT（通讯领域）的微服务，微服务架构在这两个领域的具体形态和要求是不太一样的，但其中一些思想是互通且是很有借鉴意义的。今天主要介绍一下关于微服务的 发展动态，以及最近谷歌推出的Istio平台架构。
今天介绍的主题包含：服务治理、服务网格、Istio架构，以及Istio相应的系统组成。
一、分布式计算的八个谬论
1.png
彼得多维奇多年前提出的分布式计算的八个谬论，对于开发人员来说他们往往会忽视这八条。这八条基本上都和网络相关，例如在发起一个网络请求时，会不断地做一些尝试等待，来保障消息投递的有效性。
微服务是一个更为复杂的分布式系统，之前SOA或者B/S，CS架构，它的颗粒度会更粗一点，但是如果采用微服务，它的颗粒度是更细的。在马丁·富勒博客《微服务的先决条件是什么》一文中提到一条，你必须要成为“高个子”，想成为“高个子”其实并不简单，很多公司，它们都是为了成为“高个子”，做了很多框架、平台。
二、服务治理
1、微服务治理的技术点
2.png
要成为“高个子”需要对微服务进行哪些改造，这里是相关服务治理的技术点，其中只是一部分，和服务网格比较相关的技术点，包含服务发现、负载均衡、请求路由、认证与授权、可观测性，还有健康检查、容错等。目前主流的解决方案有众所周知的SpringCloud，Dubbo等，这些都是提供库来把服务治理相关的内容打包，供具体的业务去调用。
2、库或框架的问题
但是库和框架会存在一些问题：
**1、学习成本。**多一个库对于开发人员而言，意味着要多学一些东西，并且在业务开发过程中，还会受到库或者框架的制约。
2、对业务代码的侵入性。例如用SpringCloud会在代码里面加很多额外的内容，比如每个请求里面加一个注解来表达想引用服务治理的某些功能。
3、基础库的维护、升级和下线。如果是以库的方式来提升到服务里面，库的维护、升级、下线就会造成整个服务的维护、升级、下线。
4、不同语言和技术栈。在提出微服务概念时，它的一个重要好处就是可以使用不同的技术栈来开发微服务，但如果受到框架制约，只能用这个语言，这是我们比较头痛的事情，无法发挥微服务跨语言的能力。
这些问题其实是有严重程度的，从上往下越来越让开发人员觉得不舒服。理想中的服务治理方案是什么？可以先畅想一下，整个服务治理相关的东西，应该是和业务逻辑完全隔离的，并且服务和服务之间的交互是不会考虑服务治理这块内容， 对于业务开发来说是不可见的。
这时候怎么去做呢？就引出了容器经典部署模式——Sidecar。
3、Sidecar模式
4.png
Sidecar模式通常是和容器一起使用，如果不和容器一起使用也没关系，那就是两个独立的进程，如果和容器使用的话，就基于容器为单位。Sidecar模式是物理隔离的，并且与语言无关。因为是两个独立的东西，可以独立发布，和微服务理念一样。另外它们是部署在同一个Host上面，所以资源之间可以做到相互访问，并且因为在一起所以通信延迟也不会太明显。和业务无关的功能都可以放上去，形成多个Sidecar。今天Sidecar主要是把一些服务治理相关的东西放在里面，做软件设计上的思想就是分离
转载请注明：http://www.0431gb208.com/sjslczl/6128.html
