认识达内从这里开始

云原生编程开发随着互联网的不断发展而被越来越多的程序员掌握并应用，而本文我们就通过案例分析来简单了解一下，云原生环境下的微服务架构实践。

云原生是一个很宏观的概念，如果我们以微服务为起点来看云原生给微服务带来的变化与演进，可以帮助我们更好的理解什么是云原生。

微服务和单体应用的本质是什么呢?它其实是把单体应用从一个巨型的应用拆分成数个微小的服务，然后协作来完成原先单体应用等效的业务服务。此时微服务与微服务之间会形成一个依赖关系，因此它可能会需要部署到一个或者多个资源上，这时的资源就是计算资源。

曾经的单体应用与资源之间的关系十分简单，单体应用的协同也都是一些内部协同，不存在外部动态的依赖。架构转换到微服务之后，由于外部依赖和节点数量的爆炸，整个体系会变成网状，管理起来十分复杂。超过50%的企业会觉得采用微服务架构，大挑战是复杂的运维，即整个服务生命周期的管理。

如今，比较公认的一点是云原生的根基，在于容器与容器的管理编排(K8S)。而容器与K8S的技术能帮助我们解决微服务体系存在的繁杂运维问题。

不同的微服务之间会存在异构，就是一个团队，他在微服务体系下为了发挥大效能，可能会允许不同的小团队采用不同的编程语言，甚至不同的运行环境来运行这些微服务。因此我们在运维和管理这些微服务时，初都是没有统一的标准去处理这些异构环境的。这也就是为什么后来云原生的容器技术变得非常流行，因为其作用就是通过一层标准化的封装以及标准的运行时来限制微服务部署。这样从生命周期与管理角度来说，每一个微服务之间的差异变少，比较利于资源的调度。

随后基于容器调度，就衍生出了容器平台。容器平台是什么呢?它其实就是管理容器的。就K8S来说它能够非常标准化的将微服务便捷的运行到底层的资源上。随后存储计算网络，它可以通过K8S这一层来进行统一的封装，一层抽象与封装，它就类似于云原生时代的操作系统。

它具体是提供哪些帮助呢?在K8S里面有个概念叫POD，POD其实是一组容器的结合，与微服务实体生命周期的耦合。在一个POD里面，它可以运行一个或者是多个容器。

采用微服务架构时，一般都会把微服务运行的主体放在主容器里，也就是把微服务执行的主逻辑放在主容器里面，此时主容器的生命周期与POD的生命周期是完全耦合的。即POD什么时候消亡，微服的运行主体便何时消亡。除此之外我们还会运行一些边车容器，亦称Sidecar，它主要是为主容器提供一些辅助的功能，如日志采集、网络代理身份鉴权等，都可以放在Sidecar里。这样微服务就具备了一种超能力，除了提供自身核心业务以外，它还可以动态的提供额外辅助能力，让微服务的管理变得更加健壮与便捷。

此外POD这个模型还提供了许多非常有用的功能。比如状态信息，状态信息是指：POD会提供一个标准的接口来显示运行时的状态。通过这个信息状态可以判断微服务或容器的整个运行状态。例如它是否正在运行中、业务是否已经准备好可以迎接流量的接入，它为整体的稳定性提供了保障。另一个是地址服务，地址服务就是每个POD会有一个标准化的DNS的地址服务，它对于需要统一暴露出来的API，像日志监控追踪能力都有非常大的帮助。通过DNS的日志地址来访问，或者暴露的可观测性的一些信息，可以及时发现运行时的问题。因此我们可以看到容器以及容器平台，能够在微观上帮微服务具备更多的能力。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。