云原生如何助力微服务？

随着技术的发展，我们云托管时代逐步的向云原生演进了。所谓云原生，就是将微服务、DevOps的架构理念与云所提供的容器、Serverless无服务器更好的结合，提升资源的使用效率，提高研发运维效率。那么在云原生时代，微服务应该如何与云原生相辅相成呢?

我们来看看微服务的定义，即将一个单体应用拆分成多个微服务，由微服务来一起协同对外提供服务支持。在微服务的运行中就存在这三个问题：

1、如何管理微服务的生命周期;

2、如何治理不同技术栈微服务之间的通信;

3、如何处理不同技术栈的微服务请求?

对于如何管理微服务的生命周期，我们来一起看看。最初服务都是单体式的，上线时直接部署某些机器资源上就可以了，当出现异常时，直接下线该机器上的服务版本，服务与资源的关系是比较简单的，没有动态的依赖关系。当我们把服务拆分成微服务之后，不同的微服务部署在不同的机器上，最后组成整个应用呈现给到用户，此时服务与资源的关系变得复杂起来了。如果应用是由不同的技术栈开发实现，比如有的微服务用C++、有的用Java、有的用PHP、有的用Golang，那么部署每个服务时还需要在机器上安装对应的运行环境，整个应用的运维成本又增加了。

但是在云原生时代，有了容器如Docker、容器平台技术如Kubernetes把这一切都变得简单了。Docker容器技术通过标准的封装、标准的运行时将微服务的部署变得标准化，Kubernetes技术则是把已经标准化的微服务便捷的运行在机器上，运维人员不再需要将微服务分配到某个具体的机器上，并且在Kubernetes中的Pod模型对外提供了单个容器运行状态接口、DNS地址服务，通过简单的二次开发可以看到每个微服务在哪些地址上的运行状态，简化了整个微服务生命周期的管理。

对于如何治理不同技术栈微服务之间的通信，我们一起来看看，最初服务是单体式的，模块与模块之间的通信都是静态编译产生的，比较简单。当我们把服务拆分成微服务之后，模块与模块之间的通信就是动态关联的了，微服务如何找到另外一个微服务变得复杂起来。一些微服务框架，如Java的Spring简化了开发人员的负担，只要是Java系服务的开发就不用再写一遍微服务之间通信的逻辑。

但是当一个业务引入多个技术栈时，常见的如上层用Java编写，底层用Golang编写，不同微服务之间的通信框架都不一样，无疑又增加了开发人员的成本。但是在云原生时代，我们有了ServiceMesh服务网格，通过通信劫持，实现了比较好的服务间通信监测与管理。在servicemesh中，有一个sidecar边车容器的概念，它把微服务之间通信的能力从业务中抽象，单独成一个容器与微服务并行，再使用Istio所提供的管控能力，将微服务与边车容器搭成一个网状的数据平面，在这上面进行服务之间通信的配置、管理、监测。