云原生如何助力微服务？

Posted 2021-04-03 AI课工场

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生如何助力微服务？相关的知识，希望对你有一定的参考价值。

点击上方蓝色字体，关注AI 课工场

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

云原生如何助力微服务？

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

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

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

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

对于如何治理不同技术栈微服务之间的通信，我们一起来看看，最初服务是单体式的，模块与模块之间的通信都是静态编译产生的，比较简单。当我们把服务拆分成微服务之后，模块与模块之间的通信就是动态关联的了，微服务如何找到另外一个微服务变得复杂起来。一些微服务框架，如Java的Spring简化了开发人员的负担，只要是Java系服务的开发就不用再写一遍微服务之间通信的逻辑。但是当一个业务引入多个技术栈时，常见的如上层用Java编写，底层用Golang编写，不同微服务之间的通信框架都不一样，无疑又增加了开发人员的成本。但是在云原生时代，我们有了ServiceMesh服务网格，通过通信劫持，实现了比较好的服务间通信监测与管理。在servicemesh中，有一个sidecar边车容器的概念，它把微服务之间通信的能力从业务中抽象，单独成一个容器与微服务并行，再使用Istio所提供的管控能力，将微服务与边车容器搭成一个网状的数据平面，在这上面进行服务之间通信的配置、管理、监测。

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

微服务的出现，确实推动技术向前演进了一大步，但是微服务并不是万能的，在使用它的同时，必然要承担它的复杂性所带来的成本。不过微服务确实是良药，有了云原生技术出现后，对于该良药所带来的副作用便能消解很多，云原生必定是企业落地微服务的最佳伴侣～