通俗理解容器, 微服务, DevOps, CI/CD
什么是微服务Microservices?
微服务是一种软件组织架构和方法。在微服务方法中，将一个应用软件拆分成多个独立的小型应用（也称为服务）组成，这些服务之间通过APIs接口的方式相互调用, 并最终组成一个完整的应用。
| Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs.
与微服务架构相对的则是Monolith架构，即所有的组件都紧耦合打包在一起。常见的SAP, CRM，Oracle等传统企业软件。
微服务理解
软件的架构的变化其实和现代公司架构变化有很多相似之处。
公司里面各个职能部门都可以理解为一个服务，如财务部对应财务服务，市场部对应市场服务，行政部对应行政服务，销售部对应销售服务。
过去很长一段时间内，公司规模不大，组织结构基本都是统一的财务部、市场部、销售部、行政部等各个部分，只是大小不同而已。
后来随着公司规模越来越大，这样的架构就出现了管理问题，最典型的是沟通效率，组织越庞大，沟通效率越低。
怎么解决呢？将一个大公司的业务根据各个产品线打散成多个小公司，每个小公司都各自组建自己的服务团队（财务、销售、市场、行政等），各个小公司实际上就是一个独立的公司。
那这些子公司怎么管理呢？集团化管理，各个小公司联合成集团。子公司只需向集团汇报，今年投了多少钱，赚了多少利润，此时公司之间的沟通就变得简单了。
随便找了张图，凑合着看下，大概意思如此
子公司内部，自行管理，自负盈亏，哪怕你全用自己的亲戚，财务状况一团糟，那也是你自己的事，不影响其他子公司或者集团财务，只要每年向集团交足利润即可。基本上所有的大型公司都是采用类似的组织架构。
公司新开了一条产品线，很简单，成立个新的子公司即可，不影响原有业务。
子公司之间怎么沟通呢？市场化方式运作，子公司A向子公司B采购产品或者服务，自行按照市场买卖方式处理，无需向上打报告协调。
| 当然企业组织架构设计是一门很复杂的科学，以上组织架构也只是其中一种方式。
回到软件架构中，过去大一统的软件组织架构和早期的企业组织架构一样，所有的服务都紧耦合在一起，组成一个软件包，运行的时候一起运行，这样的架构称为monolith架构。典型的如ERP、CRM等传统软件。
与企业架构的变化一样，软件架构也在像集团化的公司架构一样，将大型软件拆分成一个个独立的小服务，每个小服务提供一个最基本的功能，可以独立运行。
由于软件的拆分比公司拆分要容易的多，可以拆分地非常细，也因此习惯称为微服务，微服务顾名思义就是微小的服务。当然每个微服务都具备完整的软件结构。
所有的微服务有机地组织起来就是一个完整的大型应用。
那微服务之间怎么沟通呢？API就是各个微服务之间沟通的通信接口，大家开发时都采用统一的API语言来进行沟通。
为什么要 Microservices?
- 灵活扩展Flexible Scaling: making applications easier to scale up and down
- 易于部署Easy Deployment: faster to develop, enabling CI/CD
- 敏捷性Agility: Enabling innovation and accelerating time-to-market for new features
| 软件架构最终是为业务服务的，业务需求在快速变化，要求软件架构也要能够响应业务变化需求。
DevOps
微服务并不只有好处，也有很多弊端，最典型的是应用的部署问题。
原来研发是研发部门，生产运维是运维部门。研发部门开发好软件后，丢给运维部门一个exe之类的软件包，并交代好软件运行所需要的参数和配置就可以了。
运维部门拿到这个软件包，照着部署手册一顿操作，顺利的话软件当天就上线了，碰上开发的操作手册写的烂的话，也就两三天的事。
这样的部署操作一个月也没几次，主要是受限于软件开发部门的效率问题，你开发部门再大再复杂，到了我这里也就是一个exe软件包的事，至于内部怎么乱，那是你们的事。这个时期两个部门之间此时还可以和谐共处。
但到了微服务时代，情况就变了。
软件的开发效率成几何倍数增加了，原本运维部门只需要对接开发部门一个团队。好家伙，你开发部门把自己拆分成了大大小小几十个小团队，每人负责一个服务模块。每个部门都给我提交一个软件包和软件部署手册，我运维的工作一下子增加了上十倍。
而且你们每个部门都还TM变态，原本一个月也发布不了几次更新，现在每天每小时都在发布更新。
关键是开发的语言还不一样，Python，Java，C++都来了，运维手册写的乱七八糟，各种稀奇古怪的依赖包和版本要求。
原本一个人干完运维还可以摸摸鱼，现在人手增加了几倍，加班加点也搞不完，老子不干了，撂挑子了，你们开发写的各种乱七八糟的部署手册，自己去部署。
什么？我们自己部署？
…… 此处省略几年的争吵。
也不是没可能。
这不容器和容器编排技术来了。
于是我们就看到了最终的结果，DevOps，Dev开发和Ops运维已经没有界限了，两者已经捆绑在一起了。
分分合合，合久必分，分久必合。
容器和微服务
容器技术怎么就促进了微服务和DevOps呢？
聊起微服务和DevOps，基本都离不开容器，但这两者之间并不是必然的。只是有了容器技术，让微服务和DevOps变得更简单了。
在容器技术以前（虚拟化和裸机时代），要实现微服务和DevOps的开发方式代价非常大，所以才没有大规模发展，容器技术可以说是加速了微服务和DevOps的发展。
- 容器非常轻量，一台物理服务器上可以部署几十上百个容器。这就给微服务提供了便利，哪怕你开发把应用拆分的再细，一个应用拆成上百个微服务也没关系，照样可以用同样的硬件资源来运行。如果是在虚拟化时代就没这么方便了，一台物理服务器上运行十个虚拟机就变得很重了。
- 开发部门交付给运维的不再是软件包了，而是把软件包运行所需要的一切都打包成image镜像，运维部门根本不需要关心这个镜像中有什么，连安装步骤都省略了，直接在容器平台上拉起这个镜像就可以了。
- 在传统运维中，运维部门很大一部分工作考虑到应用的高可用，性能伸缩，负载均衡等问题。在容器化时代，这些问题容器编排工具都可以自动实现了。无需运维部分参与，开发部门在交付镜像时，顺便设置下应用所需要的一些硬件资源和部署功能需求，容器编排工具自动根据参数去部署。
CI/CD
CI/CD又是什么东西？ 全称是持续集成/持续交付Continuous integration / continuous delivery。
其实你把这个图和DevOps一比较就发现，两者是一个东西，只是换了个说法而已。都是一种软件开发和交付的思想和实践方法论。
在DevOps方法论中，开发和运维已经合二为一了。开发部门每发布一个新版本，自己直接发布到容器平台上就好了，不需要运维部分的参与。这个过程就是持续开发，持续交付（发布）的过程。