微服务，DevOps，Docker的基佬情

Posted 2021-04-16 质量管理的那些年

微服务，DevOps，Docker的基佬情

行业的现状

随着传统业务被互联网业务冲击，市场成了第一战略地段,抢下了市场企业才能更好生存，快速迭代成了一个最基础要求，应用频繁升级，三天两头要更新。

而且流量增大了，原来是线下柜台开户，现在互联网线上开户了，流量扩大了N倍。

随之带来了很多问题，比如：

• 应用无法根据业务功能伸缩，只能作为一个整体进行扩展，负载越来越大。

• 每次功能或者缺陷的变更导致重新部署整个应用，这种部署方式影响大、风险高。

• 经年累月的代码，人员变更通常通读一遍代码；每次修改代码心惊胆战，修改一个Bug极可能带来各种隐含的缺陷。

微服务

当一个系统复杂到一定程度，当维护一个系统的人数多到一定程度，解决问题的难度和沟通成本大大提高，因而需要拆成很多个工程，拆成很多个团队，分而治之。

一个字：拆！

拆开了，每个子模块独自变化，少相互影响。

拆开了，原来一个进程扛流量，现在多个进程一起扛。

所以称为微服务。

微服务和Docker

微服务场景下，进程多，更新快，于是出现100个进程，每天一个镜像。

容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。

所以微服务场景下，可以开始考虑用容器了。

容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为5-10个人专门维护这个模块的配置和更新，不容易出错。

如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。

容器是一个非常好的工具，就是让每个开发仅仅多做5%的工作，就能够节约运维200%的工作，并且不容易出错。

然而本来原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？

这就不是技术问题了，其实这就是DevOps，DevOps不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。

微服务和DevOps

拆成了微服务，然而当每个子团队将子问题解决了，整个系统的问题就解决了么？

你可以想象你将一辆整车拆成零件，然后再组装起来的过程，你就可以想象拆虽然不容易，合则更难，需要各种标准，各种流水线，才能将零件组装称为车。

• 如何控制拆的风险

• 如何保证代码质量

• 如何保证功能不变，不引入新的Bug

当然就是集成，从一开始就集成，并且不断的集成，反复的将拆分的模块重新组合，看看是否能够顺利组合起来，并且保证功能的不变。

要是不没事儿就组合一下，天知道几个月以后还能不能合的起来。

别忘了程序是人写的，你和你媳妇长时间不沟通都对不上默契，别说两个程序员了。

持续集成就是不断的尝试在一起

• 为什么需要一个统一的代码仓库Git来做代码管理呢？是为了代码集成在一起。

• 为什么需要进行构建build呢？就是代码逻辑需要集成在一起，编译不出错

• 为什么要单元测试呢？一个模块的功能集成在一起能够正确工作

• 为什么需要联调测试Staging环境呢？需要将不同模块之间集成在一起，在一个类生产的环境中进行测试。

微服务和Docker和DevOps

所以微服务，DevOps，容器是相辅相成，不可分割的。

不是微服务，根本不需要容器，虚拟机就能搞定，不需要DevOps，一年部署一次，开发和运维沟通再慢都能搞定。

所以，容器的本质是基于镜像的跨环境迁移。

如图为将容器融入持续集成的过程中，形成DevOps的流程：

在流程方面，镜像是DevOps的良好工具。