云原生：详解｜容器核心技术解析

公众号 云世​

云世

【云世】专注职场人的硬实力和软技能提升。为产品上云，微服务和云原生前沿技术和落地实践布道，分享微服务架构、容器、K8s、Service Mesh等云技术干货、案例、经验；持续发布职场做事方法论、团队管理、读书笔记，好书推荐等软技能。

先认识架构应用趋势

业界不断有架构方面的探索，从最开始的我们所熟知的这种单体架构，后来大概在10年前左右，大家又推崇面向服务的架构叫SOA server service oriented architecture。 SOA就是把业务解绑，把一个大的系统分到不同的子模块，子模块和子模块之间，通过API调用去交互的模式。

SOA架构衍生到最后出现了一个一个模块叫做系统服务总线，系统服务总线作为一个统一的API，让所有微服务之间互相调用，但是最后随着业务的复杂性提升，这个业务总线又变得巨复杂了。

然后 SOA再往前演进，衍生到了我们所熟知的微服务架构。微服务架构，可以把它理解为 SOA架构的一种最佳实践。没有强制性要求微服务和微服务之间一定要根据企业总线去通信，鼓励点对点通信，也可以说是开放一个统一的API网关，然后微服务和微服务之间互相去通信。

一个应用，一个大的系统一个大的平台，它可能会被切分成几百上千个微服务。一个业务流有可能一个用户点击了某个页面上的某个按钮，从背后来看，从真正实现来看，可能是微服务调微服务，再调微服务，有可能一个业务流后面你前端点了一个按钮，后端可能是有几百个应用在互相调用，这带给大家就是在业务架构上面带来一个什么样的挑战？

就是A服务掉B服务的时候，服务发现怎么做？

调用这个服务的地址是什么？一般都是一个IP地址加一个端口。

起一个任何的应用，都是一个IP地址加一个端口。作为一个服务提供商，发布一个服务的时候，就是要把服务发布到某一个机器机器上面，无论它是一个物理机还是虚拟机。要有一个独立的IP，一个独立端口，有一个固定访问的URL。这样服务发布出去，别人就可以来调用了。

传统的做法有两种方式，一种是物理机，可以把很多应用放上去，一台机器有一个IP。 IP可以有很多端口，把很多的服务按以不同的端口发布在这台机器上面，这样就可以发布多个服务了。带来挑战是什么？如果想发布多个web服务，他们IP一样的话，就得换端口，比如很可能80端口被别人用了，其他应用就用不了80端口了，所以早期基于物理机的进程部署，就会有这样的挑战。

随着时间发展就出了虚拟化技术，一个物理机，把它切成不同的虚拟机，每个虚拟机是一个独立的操作系统，每一个虚拟机都有自己独立的IP。在第一个虚拟机里面装一个web应用，在第二个虚拟机里面装一个web应用，它们的IP不一样，完全是不同的操作系统，这样两个web应用都可以占用80端口了。

所以通过这种方式，把资源做了切分，服务可以提供在默认端口上面，但是有不同的IP。

虚拟化带来什么问题？

虚拟化引入的复杂性，使我们的运维成本，应用的性能都会有所下降。

那么有没有更轻量级的方法来实现同样的目的？

以更简单的技术来实现异军突起的容器技术。
Docker是如何工作的？和虚拟机有哪些区别？Docker所依赖的这些技术的细节是什么？

简要介绍，docker是基于Linux内核的已存在的技术，比如说C group，namespace, unionFS. 

虚拟机架构：

一个完整的虚拟机的技术栈

• 最下面是服务器，在这个服务器基础上，要装一个host os，然后再 host os上面要装一个hypervisor。这个是在物理逻辑上所预装的软件。

• 要在这上面起一个虚拟机，hypervisor要启动了一个guest os，然后它会模拟一个完整的操作系统，包括驱动。

• 要在这个基础之上要部署应用，需要部署中间件，依赖，然后再部署应用。

这里面其实有两层操作系统。

针对虚拟化技术，最大的挑战是什么？

• 第一、任何问题的分析变得很复杂。

  比如要查一个网络问题，有可能出现在上面这一层，有可能出现在下面这一层，还有内存问题也可能是有可能是上面有可能是下面。所以它的调试就变得很复杂，性能也不会很好。因为任何的数据包进来，