在年6月Google开源了Kubernetes后，经过这几年的发展，已逐渐成为容器编排领域的事实标准，可以称之为云原生时代的操作系统，它使得基础设施维护变得异常简单。在云原生时代，微服务依赖于Kubernetes的优势在哪，微服务的生命周期基于Kubernetes该如何实践呢？本文整理自石墨文档架构负责人彭友顺在GopherChinaMeetup西安站的主题演讲《石墨文档基于Kubernetes的Go微服务实践（上篇）》。下篇会在近期整理出来，敬请期待。

互联网的WEB架构演进可以分为三个阶段：单体应用时期、垂直应用时期、微服务时期。

单体应用时期一般处于一个公司的创业初期，他的好处就是运维简单、开发快速、能够快速适应业务需求变化。但是当业务发展到一定程度后，会发现许多业务会存在一些莫名奇妙的耦合，例如你修改了一个支付模块的函数，结果登录功能挂了。为了避免这种耦合，会将一些功能模块做一个垂直拆分，进行业务隔离，彼此之间功能相互不影响。但是在业务发展过程中，会发现垂直应用架构有许多相同的功能，需要重复开发或者复制粘贴代码。所以要解决以上复用功能的问题，我们可以将同一个业务领域内功能抽出来作为一个单独的服务，服务之间使用RPC进行远程调用，这就是我们常所说的微服务架构。

总的来说，我们可以将这三个阶段总结为以下几点。单体应用架构快速、简单，但耦合性强；垂直应用架构隔离性、稳定性好，但复制粘贴代码会比较多；微服务架构可以说是兼顾了垂直应用架构的隔离性、稳定性，并且有很强的复用性能力。可以说微服务架构是公司发展壮大后，演进到某种阶段的必然趋势。

但微服务真的那么美好吗？我们可以看到一个单体架构和微服务架构的对比图。在左图我们可以看到一个业务可以通过Nginx+服务器+数据库就能实现业务需求。但是在右图微服务架构中，我们完成一个业务需要引入大量的组件，比如在中间这一块我们会引入DNS、HPA、ConfigMap等、下面部分引入了存储组件Redis、MySQL、Mongo等。以前单体应用时期我们可能直接上机器看日志或上机器上查看资源负载监控，但是到了微服务阶段，应用太多了，肯定不能这么去操作，这个时候我们就需要引入ELK、Prometheus、Grafana、Jaeger等各种基础设施，来更方便地对我们的服务进行观测。

微服务的组件增多、架构复杂，使得我们运维变得更加复杂。对于大厂而言，人多维护起来肯定没什么太大问题，可以自建完整的基础设施，但对于小厂而言，研发资源有限，想自建会相当困难。

不过微服务的基础设施维护困难的问题在Kubernetes出现后逐渐出现了转机。在年6月Google开源了Kubernetes后，经过这几年的发展，已逐渐成为容器编排领域的事实标准。同时Kubernetes已俨然成为云原生时代的超级操作系统，它使得基础设施维护变得异常简单。

在传统模式下，我们不仅需要

转载请注明:http://www.aideyishus.com/lkcf/16.html