微服服务：云原生对微服务的益处有哪些

　　云原生是基于分布部署和统一运管的浪潮式分布云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。云原生，就是将微服务、DevOps的架构理念与云所提供的容器、Serverless无主机更好的结合，提升资源的使用效率，提高研发运维效率。

　　微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成，即将一个单体应用拆分成多个微服务，由微服务来一起协同对外提供服务支持。

　　在微服务的运行中就存在这三个问题：

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

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

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

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

　　那么云原生对微服务的益处有哪些？

　　1.简化了整个微服务生命周期的管理

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

　　2.现了比较好的服务间通信监测与管理

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

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

　　3.无需重复写请求逻辑

　　对于如何处理不同技术栈的微服务请求，我们一起来看看，原来的外部请求通过浏览器或app进来之后，会经过应用层/网络层的负载均衡决定分发给到哪台机器去处理，单体式应用因为是一个大整体，直接分发即可，还是比较简单的，而微服务则需要经过复杂的逻辑判断给到哪个服务、哪台机器。在多技术栈开发的情况下，每个微服务框架都需要写一遍请求逻辑。但是在云原生时代，我们有了Serverless无主机的概念，我们可以把请求类型、请求管理、请求处理的逻辑全抽出来标准化，在业务层只需要前端去调用该函数即可，后面的请求处理分发就再也不用管理了。

　　以上就是云原生对微服务的益处，微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间，但是它的复杂性所带来的成本也很大，但有云原生的助力，能消解很多微服务的副作用，因此云原生能很好的助力企业落地微服务。