云原生技术加速ServiceMesh去中心化微服务治理的推进

　　对于ServiceMesh服务网格和ServerLess无服务器化，我在前面写过多篇文章进行阐述，今天准备就里面的一些关键点再进行总结和思考。
　　就两个云原生阶段的关键技术来讲，ServiceMesh当前发展迅速，特别是类似Istio的开源实现，当前已经被逐步开始大面积采用，包括一些大集团内部的云原生技术平台中，也采用这种方式来实现微服务治理方面的工作。而对于ServerLess无服务器化，虽然这个也是处于相对火热的状态，但是要在企业传统IT信息化中发挥作用，为时尚早，这个我在后面也会进一步阐明观点。
　　对于两者可以先参考我前面的文章：
　　谈ServiceMesh微服务治理在云原生解决方案中作用
　　你应该了解的Serverless无服务器架构和应用场景
　　对于我在前面已经描述过的一些内容，在这篇文章中就不再重复进行介绍，这篇文章仅阐述我对两者的一些关键点思考和总结。为何需要ServiceMesh进行微服务治理
　　微服务治理是一个系统课题，这个我在前面专门讲微服务治理的文章中有过说明，即包括了微服务全生命周期的管理，需求，设计，监控，运维，标准规范流程等。
　　在传统架构阶段，会谈SOA治理。
　　而SOA治理往往就会谈到引入SOA集成平台或ESB服务总线来实现接口服务的一系列管控治理操作，包括了服务安全，日志审计，流量控制等。但是基于ESB总线的服务治理本身是一种中心化和集中化的治理模式。
　　其次传统ESB本身还承担了大量的遗留协议转换适配，数据映射等操作，这也简单导致了ESB总线本身越来越重，难以进行管控和运维。
　　去中心化的治理模式
　　当前主流的微服务架构，本身是一种去中心化的架构模式，因此微服务治理本身也是去中心化的。而对于服务注册发现中心，本身可以作为服务治理的一部分，但是无法完成所有的服务治理工作。
　　也因此看到服务限流熔断，服务安全，负载均衡等往往还需要其它组件的配合，共同来完成微服务治理过程。
　　一个微服务架构应用，如果涉及到对外发布服务，往往还涉及到API网关，而API网关本身也是一种中心化的架构模式。这也是我经常强调的，并不是说一个微服务架构体系就完全去中心化了。
　　能否以一个框架完成所有治理工作？
　　能不能用一个框架来完成所有的服务治理工作，而不是多个组件的集成来完成。同时这个框架本身又是去中心化的架构。
　　实际在微服务注册发现的各种开源解决方案中，为了更好的去中心化，已经有类似Consul等方案本身就会在微服务端内置SDK代理包。那么是否有一个更好的去中心化方案能够将注册发现，限流熔断，安全，日志审计等各种服务治理能力全部接管呢？
　　在远行科技很早实施ESB总线项目的时候，就曾经在思考去中心化的问题 ，当时就想到可以将ESB总线的拦截能力通过Java SDK代理包的方式下沉到各个业务系统中去，同时进一步实现服务调用的管控流和数据流分离。
　　这本身也是当前的ServiceMesh思路完全一致。
　　简单来说当前的ServiceMesh服务网格的思路就是通过下放Sidecar边车到各个微服务中的方式来实现管控流和数据流的分离，并彻底的去中心化。为何ServiceMesh会成为趋势
　　既然通过下放SDK代理可以彻底地做到去中心化，那么在传统ESB项目实施中我们为何很少地使用这种方式。
　　其一就是传统遗留系统集成，往往涉及到复杂的协议转换适配，数据映射等操作，这些操作本身偏重，不是简单的可以下发一个轻量SDK包就能够搞定的事情。其二就是传统中心化建设模式，本身就是为了更好地管控，但是下放SDK代理包，那么对于SDK包如何使用，如何配置，后续如何更新都将带来一系列的运维和管控问题，也就是说一个企业IT治理成熟度不足够的时候，采用这种去中心化反而增加了复杂度。
　　而在微服务架构模式下，API接口都变为标准的Rest API接口模式，不存在复杂的协议转换，数据映射场景，因此SDK包只需要处理接口安全，限流，负载均衡等标准的管控治理事项即可。
　　那么对于前面谈的SDK包安装，后续变更问题如何解决？
　　如果要在应用或微服务中安装SDK包，也就是当前ServiceMesh中的Sidecar，一个核心的述求就是我们希望这个代理包对应用是透明的，对应用是无侵入的。
　　如果需要人为去安装配置，去处理版本更新，那么显然达不到上面这个要求。
　　然后随着云原生，特别是容器云和DevOps的发展，这个问题得到了很好的解决，即我们可以在自动化的服务部署和交付过程中，自动的下放这个代理包，同时在边车模块有更新的时候我们也可以实现自动化的重新部署或灰度发布。
　　对于微服务来说，完全可以不用关心Sidecar的存在。
　　即通过服务网格，实现了一个关键的能力。
　　对于微服务开发者来说，只需要按照标准的微服务开发框架来开发微服务接口，而不需要在开发阶段考虑任何和服务治理有关的配置属性，所有的治理能力都应该是后续通过Sidecar边车模式实现的外挂。
　　如何兼容不同的开发框架？
　　大家都知道，实际上当前有SpringCloud，Dubbo等各种不同的微服务开发框架，包括类似华为，阿里，腾讯也都封装有自己的微服务开发框架。
　　实际上如果一个大的应用场景，各个开发商有不同的微服务开发框架，往往就存在多套微服务治理方式难以统一。
　　而当前在ServiceMesh服务网格下，这个问题反而变得更加简单，即我们只需要针对不同的微服务开发框架提前定制不同类型的Sidecar边车模块。然后在微服务部署的时候，根据微服务开发框架类型的不同，自动地下发对应的边车代理即可。
　　Kurbernetes和服务网格配合
　　在前面谈到，如果边车模块是人工部署，人工变更的模式，那么这个去中心化的管控方式并不成立，而随着DevOps发展，DevOps和容器云融合，实现了微服务的自动化部署，持续集成和持续交付。
　　也就是说通过Kurbernetes实现了微服务应用托管，容器的自动编排，容器的弹性扩展能力，那么在这个自动化部署过程中我们可以很好的通过非侵入的方式下发边车模块。
　　其次Kurbernetes集群本身已经很容易实现服务的统一注册管理，集群负载均衡等微服务治理管控能力，因此在Kurbernetes的基础上来扩展类似Istio等开源服务网格实现是合理的。即进一步扩展安全，限流熔断，日志审计，服务链路监控等扩展微服务治理管控能力。
　　是否还需要服务注册中心和API网关？
　　首先看下是否还需要服务注册中心。
　　我在前面已经谈到Kurbernetes本身已经覆盖了大部分的服务注册中心的功能，包括服务注册，服务发现，负载均衡等，这些都可以通过Kurbernetes来实现。
　　在原有的技术方案里面，有时候会考虑将Eureka注册中心再和Kurbernetes进行集成，但是实际上基于Kurbernetes来定制服务注册中心相关能力并不困难。而对于传统的微服务架构中的微服务网关能力，则完全可以通过类似Ingress来替代。
　　也就是说通过Kurbernetes基本可以实现传统微服务架构中的服务注册发现，负载均衡，统一配置发布，网关等各种关键能力。
　　那么对于限流熔断能力，在传统微服务架构里面是通过独立的组件来实现的。类似SpringCLoud框架中的Hystrix或者独立的Sentinel开源实现等。而这部分能力，在使用了ServiceMesh解决方案后，这部分内容则下发到Sidecar边车模块中进行实现。
　　包括负载均衡等能力，也可以下发到Sidecar中进行均衡和路由。
　　对于ServiceMesh主流的开源实现Istio里面，也可以看到该开源框架旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。Istio 项目能够为微服务架构提供流量管理机制，同时亦为其它增值功能（包括安全性、监控、路由、连接管理与策略等）创造了基础。
　　其主要实现如下四个方面能力：连接（Connect）：智能控制服务之间的调用流量，能够实现灰度发布等功能安全加固（Secure）：自动为服务之间的调用提供认证、授权和加密。控制（Control）：应用用户定义的 policy，保证资源在消费者中公平分配。观察（Observe）：查看服务运行期间的各种数据，比如日志、监控和 tracing
　　可以看到，Istio 这就是我们上述提到的 Service Mesh 架构的一种实现，服务之间的通信（比如这里的 Service A 访问 Service B）会通过代理（默认是 Envoy）来进行。而且中间的网络协议支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以说覆盖了主流的通信协议。
　　Istio是一个与Kubernetes紧密结合地适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。在我们实施微服务+DevOps+容器云的过程中，为了实现完全的去中心化，并增加对微服务模块，API接口服务的治理管控能力，和ServiceMesh思路进行结合是一个必然的发展趋势。
　　从微服务到微服务API治理
　　对于微服务治理实际包括两个层面，传统的微服务治理只谈到微服务级别的治理，这里的微服务实际是指的微服务模块粒度。
　　实际上微服务治理还应该到更细化的微服务暴露的API接口服务的治理，这块是传统架构里面的SOA集成平台或ESB总线来完成的内容。在当前微服务架构里面，也可以通过API网关来完成相关的API接口治理工作。
　　在前面谈到在采用ServiceMesh后，实际上不再需要服务注册中心，同时也不可能再引入中心化架构的API网关能力。因此对于API接口粒度的服务治理能力，就需要在ServiceMesh框架中来实现，这种接口治理能力也需要下发到Sidecar边车模块来实现。
　　一个微服务对外暴露10个API接口。
　　那么整个微服务治理管控实际是需要管控到每一个API接口服务层面。包括对这个API接口本身的安全访问控制，接口限流熔断，接口调用日志审计能力等。