有容云：微服务容器化的挑战和解决之道

摘要： 本文讲的是有容云：微服务容器化的挑战和解决之道， 注： 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成，演讲者：有容云联合创始人兼首席架构师马洪喜，与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地。

注：

本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成，演讲者：有容云联合创始人兼首席架构师马洪喜，与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地。

嘉宾介绍：

马洪喜，此前担任 Rancher Labs 中国区技术负责人、Citrix 公司资深架构师、Oracle 公司虚拟化产品开发经理等职务，在容器云、IaaS 云、桌面云建设方面拥有丰富的经验。

单体架构 VS 微服务架构

传统单体架构存在各种各样的问题，如加载编译耗时长、代码管理复杂、横向扩展难、各模块之间的耦合程度高等，与之相比，微服务架构则具一系列优势。

微服务架构则优势：

1. 模块可以独立提供服务，边界清晰、易于维护，可以促成新的开发模式，使模块外包，未来微服务模块市场的出现成为可能。

2. 微服务可以用不同语言编写，易于引入新技术。

3. 未来可能会形成微服务应用商店模型，快速的组合和重构。

4. 模块间松耦合，不同 SLA 保障计划。

5. 更好的可扩展性和鲁棒性。

下面我们看一个微服务的架构示例 ：有容云AppHouse。

image.png

上图是 AppHouse 采用的架构设计。按照服务职能的切割，每一个微服务都跑在一个或者一组容器中，迎合了微服务主流的设计思路。

微服务和容器发展不可分割，以前存在各种各样切割服务的难点，而容器技术的出现使得服务可以切割得更小，成为支撑微服务很好的平台。下面让我们看看在非容器化的传统的 IT 基础设施之上，如果尝试使用微服务会存在哪些挑战。

image.png image.png image.png image.png

容器可以轻松实现微服务化后的 DevOps

Netflix 云架构总监说微服务和 Docker 的结合是一种颠覆。Docker可以为微服务提供一个完美的运行环境。

1. 独立性。一个容器就是一个完整的执行环境，不依赖外部任何的东西。

2. 细粒度。一台物理机器可以同时运行成百上千个容器，其计算粒度足够的小。

3. 快速创建和销毁。容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。

4. 完善的管理工具。数量众多的容器编排管理工具，能够快速的实现服务的组合和调度。

微服务化与容器化，谁先谁后?

image.png

目前，许多传统企业都非常关注微服务。但是，我们需要意识到，利用容器技术将传统系统进行微服务改造不可能一步到位，并且也不是一定要把你的应用改造成微服务。

微服务改造本身是一个漫长的过程，如果你是 SOA 的应用，甚至是更传统的，那么可以考虑先将应用转到容器平台上运行，然后我们可以先体验容器带来的感受，再考虑如何将应用往微服务方向改造。

支持微服务的容器管理平台需要解决的问题

image.png

在容器上跑微服务是所有人的共识，问题在于如何支撑微服务。从管理微服务的角度看，未来微服务需要实现跨主机、跨云、跨数据中心。当系统被微服务打散后，一些功能需要放到阿里云，一些功能需要放到企业中心，如何在服务平台上实现跨云的管理，这是带给容器管理平台的挑战。另外，一部分微服务跑在阿里云，一部分微服务跑在本地，如何保证它的安全性，并且按照预想的安全策略去做也是一个挑战。

大家知道，微服务通过一组功能相同的微服务实例，对外提供统一的服务。当微服务实例扩容时，如何让它们自动的提供服务，不需要手动调整负载均衡配置，这也是容器管理平台需要考虑的问题。此外，容器管理平台还要实现服务的注册和服务的发现、微服务版本的管理和微服务的升级与降级等，这个过程需要考虑到灰度发布策略和已有会话的处理等工作。当然，这只 是一部分例子，除此之外还会涉及到生命周期管理、团队协作和应用配置管理等各个方面的功能点。

面向微服务的容器网络和存储实现架构讨论

image.png

接下来和大家分享一下使用容器进行微服务支撑的另外两个技术挑战点：

第一个挑战是微服务模式下如何使用容器网络。

大家关注容器技术，知道容器的网络发展速度很快，比如 CNI、CNM 等各类网络模型出现。在谈容器网络的时候，大家很容易会陷入一个误区，即过度追求技术的时尚性，例如 Overlay , SDN 等等，这些技术与容器配合当然是未来的方向，但今天考虑把容器技术真正落地，隧道网络不一定适合每个企业。很多企业既希望容器像虚拟机一样直接使用业务 IP ，又不希望 IP 资源过渡消耗。因此产品设计要关注用户的实际使用需求。

第二个挑战是微服务模式下的容器存储方案。

一个大的系统，不同的微服务模块，对包括存储、计算、网络都有不同的 SLA 要求，譬如做数据处理的模块与做图片归档的模块对存储要求是不一样的。是不是有一天我们定义应用对接存储的规格时，可以通过写一行配置参数，不同的存储指向和 SLA ，比如数据处理模块对接到跨多主机 SSD 盘阵的分布式存储上，图片归档可能是放在 SATA 盘阵或是公有云存储，比如七牛云上呢。这可能是未来支持微服务的平台必须具备的功能之一。

刚才提到，微服务时代似乎确实需要极强的容器管理平台，帮我们更好的管理微服务。而这样一个平台需要考虑到多方面功能点，以下是一些成熟的容器管理平台要解决的问题。

image.png

在产品设计上，我们在思考有没有好的方式，能够根据用户量访问情况做到对微服务模块的自动扩容( AutoScale )，这也是大家比较关心的问题。否则花了很大力气改造微服务，做完后却发现这个平台不具备根据用户的访问自动扩展服务的能力，微服务的价值也大打折扣。

微服务容器化下的安全架构考虑

每个企业都会关心信息安全。上了容器后，大家也会关心如何解决容器环境下的安全挑战。

传统的模式不太适用于新的容器时代或者微服务时代

1.jpg 动脑java.png 动脑java3.png 动脑java4.png