浅谈微服务架构、容器技术与K8S

关注嘉为科技，获取运维新知

 

企业应用系统：从单体应用走向微服务架构；从裸金属走向容器。

 

如果在诸多热门云计算技术诸如容器、微服务、DevOps、OpenStack等之中，找出一个最火的方向，那么可能非微服务莫属。尽管话题炙手可热，但对传统行业来说，微服务落地和方法论目前处于起步阶段。

 

单体架构

对于传统企业来说，数字化转型的需求日益迫切，其IT架构面临着互联网融合业务中海量用户和快速迭代的巨大挑战。当前，我们所开发的应用，不管是运行在局域网中还是部署在云端的，都采用了单体架构、分布式架构或微服务架构其中的一种。

 

其中，采用单体架构的应用数量最多，我们将这种应用简称为单体应用。我们可以将单体应用理解为主要的业务逻辑模块（我们编写的代码模块，不包括独立的中间件）运行在一个进程中的应用，最典型的是跑在Tomcat中的Java Web应用，不管这个应用在内部划分了多少模块，以及是否采用了MVC的分层架构，它都是一个单体应用，因为所有模块都运行在一个Tomcat容器中，位于一个进程里，如图所示是目前应用最为广泛的基于Sping Framework的单体应用的架构图。

 

单机应用有哪些好处和劣势呢？

 

好处

• 技术门槛低

• 编程工作量少

• 开发简单快速

• 调试方便

• 环境容易搭建

• 容易发布部署及升级

• 无论是开发还是运维，其总体成本都很低且见效快

   

劣势

• 单体应用的系统比较膨胀与臃肿，导致进行可持续开发和运维很困难。

  例如：一开始，我们的系统只有10个模块，随着业务的扩展，一年后变成了30个模块，两年后达到80个模块。项目的工程代码由于过于庞大，很多代码被不断修改，整个系统的源码已经很难被理解和掌握了。

   

• 单体应用在基因上的缺陷导致它很难通过水平扩展、多机部署的方式来提升系统的吞吐量，一般只能通过纵向不断堆单个机器或者群集的性能配置来提升。

  这样的结果就是系统难以承载迅速增长的互联网用户引发的请求，也就是说，在用户规模增加后，即使不断升级服务器硬件并进行各种性能调优，系统也会动不动就“挂了”。

   

• 单体应用的多个模块在代码级别没有明确的接口与界限划分，在修改已有代码时，经常牵一发而动全身。在传统单体架构下，应用如果频繁升级更新，开发团队非常