微服务和DevOps，容器云加速ServiceMesh服务网格落地

　　注：今天这篇文章更多为产品规划，DevOps实践过程中的一些思考总结，个人会尝试在这里文章中减少配图，通过文字的方式来将自己的观点说清楚。
　　在我对云原生整体解决方案的思考中，微服务治理始终都是一个关键，而谈到微服务治理一定会谈到从传统中心化的通过API网关来实现的治理转变到彻底的去中心化的ServiceMesh服务网格来实现。
　　对于ServiceMesh服务网格本身也是云原生中的一个核心技术要素，Mesh化不仅是实现微服务治理，而是真正加速推进了微服务，DevOps和容器云技术之间的融合。ServiceMesh是下一代微服务
　　对于ServiceMesh经常有人提到是下一代的微服务，或者说通过ServiceMesh来替代类似SpringCloud等主流的微服务框架。
　　对于SpringCloud架构体系我们需要理解为开发态和运行治理态两个方面的内容，其一个是为开发态提供的开发框架，环境和组件；其次是在运行态提供的各种微服务治理能力，比如服务注册发现，限流熔断，安全等。
　　那么ServiceMesh实际上是希望将SpringCloud框架在运行态提供的各种服务治理管控能力全部替代掉，而仅仅保留开发态的能力。即使你在开发态仍然可以使用Spingboot来进行微服务开发，来通过声明式的方式发布Rest API接口服务。
　　即这个时候的重心仅仅在于你采用一个技术来开发一个微服务组件，同时这个组件能够暴露外部可以访问的Rest API接口。同时这个组件足够轻量化，可以很容易部署到容器中。
　　你可以采用SpingBoot来开发，你也可以采用传统的Spring+CXF来开发这个微服务。ServiceMesh并不特意去强调你用什么框架来开发微服务+API，只要能够提供可以访问的微服务地址+API地址给ServiceMesh接入和注册即可。
　　包括你还可以用go语言来开发你的微服务，并接入到ServiceMesh，在这种情况下仅仅是ServiceMesh为Go语言定制一个特殊的Sidecar边车组件。开发和管控治理得彻底分离
　　对于这点，实际上我已经强调过很多次了。
　　还是拿Springcloud框架来举例，可以看到当你在开发的过程中，为了满足后续的治理管控要求，你会增加相应的配置文件编写，增加注解说明，或者还需要增加相应的Java类文件和代码。而这些并不是为业务功能和逻辑实现服务。
　　这些额外的工作仅仅是为了后续微服务管理和治理。
　　那么在这种方式下，如果微服务管控治理的规则发生了变化，对于一些无法通过配置中心动态下发的内容，势必还涉及到代码级的修改并重新打包部署。也就是治理管控需求反而影响到微服务组件本身的稳定性。
　　而我们真正需要的是管控治理和开发的分离。
　　其一就是在开发状态和开发过程中，不需要为了后续的管控治理来增加任何开发工作量和开发代码，开发配置等。也就是说对于开发人员来说，开发只关系业务功能和业务规则逻辑的实现，在开发阶段不用去考虑任何涉及到微服务治理管控的技术内容。这样才能够让开发仍有更加专注于业务功能的实现。
　　其二就是管控治理功能和微服务业务功能彻底分离。这个分离在ServiceMesh里面可以看到通过Kurbernetes将微服务部署到Pod里面的时候，会单独再为Sidecar创建一个容器，微服务容器和Sidecar容器在一个Pod里面，几方面接口协同，又实现了相互之间的解耦和隔离。
　　即使Sidecar本身出现变更或功能增加，也不会影响到微服务本身。DevOps过程实践加速推进ServiceMesh
　　在前面谈ServiceMesh相关文章里面提到，对于ServiceMesh的Sidecar是做为一个独立的代理组件下发到微服务端的，而且对已有的微服务本身无任何侵入。
　　如果这个代理包的下发和部署都需要人工去完成，那么整个工作量巨大，同时也不方便后续的管控和升级。因此在整个ServiceMesh的推广实施中一定就涉及到该部分工作的自动化。
　　如何自动化？
　　对于云原生本身就在做CI/CD的持续集成和持续部署的实践，我们通过编排可视化的流水线来完成编译，构建，打包，部署整个过程的自动化。也正是有了这个基础，我们也很容易想到可以在自动部署的时候将Sidecar代理模块自动部署下去，在整个过程中不需要人工干预去处理，这个过程完全自动化。
　　也就是说对于微服务治理能力的实现，从边车的下发，后续的治理管控等对于微服务开发本身都是无感知的，无侵入的，而且整个过程通过DevOps实践来实现了完整的自动化。
　　开发人员只需要开发微服务，但是开发的微服务通过DevOps+容器云，天然具备了后续的微服务管控治理能力，不会担心后续的微服务无法管控，无法监控等。云原生-彻底的从资源到服务
　　云原生的文章我写了很多，其中始终都在强调的一个观点就是从资源到服务，整个云计算演进的过程就是不断地向上抽象的过程。
　　基于这个思路我们再回来看下微服务和云原生，容器云的融合。
　　也就是当我们采用类似Springcloud框架体系的时候，这个框架体系既包括了开发态的内容，也包括了运行态的微服务治理内容。也就是说当你将开发完成的微服务部署到测试环境或生产环境的时候，你必须要提前部署类似注册中心，微服务网关这些组件。
　　那么如何部署这些组件？
　　常规的容器云PaaS平台并不会提供这些能力，那么在这个时候你就需要去订购虚拟机，自己在虚拟机上面安装这些组件服务，而这部分内容实际是无法通过DevOps和容器云自己进行的，这些动作全部是在DevOps，容器云，PaaS平台服务体外循环。
　　也就是说本来需要完全面对服务，但是又接触到了资源层的虚拟机资源。
　　在这种场景下，我们开发完成的微服务的部署，交付过程并没有想象的那么简单，为了微服务管控治理需求，而增加了部署，交付的复杂度。同时又面对了底层资源。
　　而我们希望的是你的整个应用开发，交付都完全能够通过DevOps+容器云PaaS平台进行，彻底从资源层抽象到服务层。在这个云原生整体推进的大目标下，可以看到通过ServiceMesh来代替传统的微服务治理就势在必行，也是大趋势。
　　包括我们自己做DevOps支撑平台和容器云平台，也需要在整个产品和最佳实践中完整地融入ServiceMesh的能力。在我前年谈的时候实际类似Istio等开源实现并不是很成熟，而最近1到2年却已经得到更大面积的采用和实践。
　　特别是在DevOps推进过程中本身也加速了ServiceMesh的落地。