深入理解容器技术——聊聊服务容器化三大助力

服务容器化三大助力

我们都知道，微服务的落地有众多需求，容器化技术是它的不二之选，容器化通过三大助力来实现了微服务落地的众多需求：

• 码头林立——各种软硬件平台层出不穷
  容器化解决方案具有一个普适性，它适用于各种不同的软硬件平台。
• 微服务——高内聚、低耦合、分钟启停和部署
  这一点体现的就是容器化的微小型，能做到分钟级的启停和部署
• 康威定律——组织决定上层建筑
  容器化技术是一个比较抽象的技术，它剥离了很多运维的工作量，更适合我们当前比较热点的DevOps，更适合于我们互联网架构在康威定律下做的一些企业的变化，同时也需要我们应用走向一个变化。

码头林立

从虚拟化的角度来看，我们大量的操作系统不会直接在物理机上，而是在虚拟化平台上，这大量的存储、服务器、虚拟化、操作系统来决定了我们有各种各样不同的码头，不管是静态网页，还是java代码，还是nodejs应用，甚至是一些底层的中间件应用，也有微服务改造中出现的新的应用。
怎么成功的承载到这些码头上呢？是不是所有的应用对所有的平台都要做一次兼容性测试，我们通过大量反复的测试来验证这些应用可部署，来让我们每个开发人员、架构师来了解这些兼容性呢？

答案是否定的，不管你的货物是通过火车，通过汽车还是通过飞机或者轮船运，它通常不是把货物直接放在机舱里，或者放在轮船的船舱里面，而是把他们放在一个长宽高比较固定的立方体里面，也就是集装箱，这个集装箱可以很方便的从飞机搬运到火车，又从火车搬运到轮船，它适合与不同的虚拟化技术、操作系统、服务器技术、存储技术、网路技术，这些容器就相当于我们的集装箱，他们的英文单词都是Container，那就是码头林立的环境当中，容器通用性解决了我们不同应用和不同软硬件平台的兼容性问题。

微服务

第二点就是我们上面所说的微服务的“微”，“微”就意味着通常我们的代码不会是几个G的很大的代码，而是只有几M、几十M、几百M小应用代码，微也就意味着我们应用的发布不需要几个月，甚至半年长期的发布流程，它的迭代很快，可能是几小时，可能几天，“微”另一个层次就是说应用的启停是很快的，秒级或者分钟级是微服务常见的一种启停情况，而通常传统的原生态的应用需要几十分钟甚至是几小时。

就像上图中，左边这种大的方块中的应用已经不太适合，它会把所有的应用提取成不同的微服务模块，每一个模块会成为一个小方格，这个小方格就会运行在不同的虚拟机、不同的物理机、不同的操作系统上，所以我们希望把每一个小方格都放在一个集装箱里，这个集装箱，就是我们的容器化技术。

如上图所示，之前我们的应用是把一大堆小的服务堆成为一个大的应用，部署在一台物理机上或者一台虚拟机上，那这个虚拟机需要大量的内存、需要大量的计算单元、还需要独立的操作系统承载它整个这一套的应用。

我们再看看下图：

到了我们刚刚第一张图中说的小方格以后，如果一个小方格还占据一个操作系统、占据一个独立的CPU内存空间，这样的资源消耗是非常大的，以我们微服务改造之前的单体应用为例，我们只需要一两个虚机就能完成，但如果我们微服务改造完成后，这样上百个微服务都需要虚机来完成，那就需要几百台虚机，这还不考虑高可用，不考虑数据备份容灾的情况下，如果有高可用、性能要求、容灾考虑进去，我们就可能需要上千台虚机，可以想象我们数据中心的承载压力有多大，那如果有容器化会怎样呢？
所有这些微小的内容成为一个把Runtime和应用打包好的一个微小体，这个微小体代码可能有20M，我们打包完以后可能有30M，那原来的代码的启停在一个操作系统里面，包括操作系统启停、数据库启停、应用启停，可能是几十分钟，在我们容器化里面，可能就是十几秒到几分钟，通过这样一个技术我们仍然可以把它几百个不同的这些微服务在一台操作系统上运行起来，那为了实现高可用我们可能有多个操作系统，那通过这样一个比较，微小的容器化部署方式能够实现所有微服务很方便在各个地方飘来飘去，但是不受限与硬件平台的制约，这就是我们微服务和我们容器化相耦合的一个点。

康威定律

这一点就是我们当前互联网的根本性，或者说是最大的变化，在互联网的发展或者电商的发展前期，我们通常一个部门，比如开发部门，这个部门既负责我们电商里面的支付、告警、订单管理、用户管理、买和卖业务流程的管理，同时我们的运维部门搭建整个数据中心，完成所有虚拟机的环境，所有网络的接入，同时还有可能需要提供底层的数据库，比如底层API对外暴露的一些网络的负载均衡，内容缓存的这些功能，他们是一个大的耦合性很弱的一个部门，相对独立，有互相制约，为了满足我们互联网不停的新需求发展，很多公司在组织上做了很大的调整，把开发、测试、运维独立成一个个小的事业组，一个事业组负责用户，它既负责用户这部分代码的开发，也负责质量检测以及落地和实施；另一个事业组可能是做支付，这个支付可能既包含它应用的架构，包含它部署的架构，也包含对客户提供实际的响应服务，如果支付平台坏了，他们提供24小时的响应，这就是我们一种组织结构的变化，按照我们现在比较流行的康威定律来说就是组织架构决定上层建筑。

当一个公司有一个怎么样的组织架构，他就有一个怎么样的业务形态，或者一个什么样的IT系统，那么要求任何一个组织的IT系统，他们的成员其实大部分还是我们工程师，以我们当前最热的Java为例，就是我们的java架构师、研发人员和我们Java平台的测试人员，以他们为主体，那么你要完成基本的所有业务系统的QA发布，准生产发布以及生产平台弹性的、可扩缩容的、高稳定性的发布，要求我们每个Java架构师和我们Java的开发人员，对系统的运维要有很深入的了解，这样其实有些现实。
那容器化技术是怎样解决的呢? 容器技术是要我们有一个统一的容器平台，搭建在一个开源的或者是一个第三方支撑好的一个平台上，那对我们研发人员来说，只要了解好这个平台的特征，学会怎样通过这样一个平台发布一个应用，这个平台自动的完成我们扩缩容啊、高可用啊、快速启停啊，这满足了我们组织结构变化了以后，对我们所有系统、所有的架构师、所有的开发人员，没有太多的额外要求，非常之普适于我们组织结构的变化，甚至是实现了我们微服务改造过程当中遇到的很多的问题。