|
单体架构 VS 微服务架构
传统单体架构存在各种各样的问题，如加载编译耗时长、代码管理复杂、横向扩展难、各模块之间的耦合程度高等，与之相比，微服务架构则具一系列优势。
微服务架构则优势：
1. 模块可以独立提供服务，边界清晰、易于维护，可以促成新的开发模式，使模块外包，未来微服务模块市场的出现成为可能。
2. 微服务可以用不同语言编写，易于引入新技术。
3. 未来可能会形成微服务应用商店模型，快速的组合和重构。
4. 模块间松耦合，不同 SLA 保障计划。
5. 更好的可扩展性和鲁棒性。
下面我们看一个微服务的架构示例 ：有容云AppHouse。
上图是 AppHouse 采用的架构设计。按照服务职能的切割，每一个微服务都跑在一个或者一组容器中，迎合了微服务主流的设计思路。
微服务和容器发展不可分割，以前存在各种各样切割服务的难点，而容器技术的出现使得服务可以切割得更小，成为支撑微服务很好的平台。下面让我们看看在非容器化的传统的
IT 基础设施之上，如果尝试使用微服务会存在哪些挑战。
容器可以轻松实现微服务化后的 DevOps
Netflix 云架构总监说微服务和 Docker 的结合是一种颠覆。Docker可以为微服务提供一个完美的运行环境。
1. 独立性。一个容器就是一个完整的执行环境，不依赖外部任何的东西。
2. 细粒度。一台物理机器可以同时运行成百上千个容器，其计算粒度足够的小。
3. 快速创建和销毁。容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。
4. 完善的管理工具。数量众多的容器编排管理工具，能够快速的实现服务的组合和调度。
微服务化与容器化，谁先谁后?
目前，许多传统企业都非常关注微服务。但是，我们需要意识到，利用容器技术将传统系统进行微服务改造不可能一步到位，并且也不是一定要把你的应用改造成微服务。
微服务改造本身是一个漫长的过程，如果你是 SOA 的应用，甚至是更传统的，那么可以考虑先将应用转到容器平台上运行，然后我们可以先体验容器带来的感受，再考虑如何将应用往微服务方向改造。
支持微服务的容器管理平台需要解决的问题
在容器上跑微服务是所有人的共识，问题在于如何支撑微服务。从管理微服务的角度看，未来微服务需要实现跨主机、跨云、跨数据中心。当系统被微服务打散后，一些功能需要放到阿里云，一些功能需要放到企业中心，如何在服务平台上实现跨云的管理，这是带给容器管理平台的挑战。另外，一部分微服务跑在阿里云，一部分微服务跑在本地，如何保证它的安全性，并且按照预想的安全策略去做也是一个挑战。
大家知道，微服务通过一组功能相同的微服务实例，对外提供统一的服务。当微服务实例扩容时，如何让它们自动的提供服务，不需要手动调整负载均衡配置，这也是容器管理平台需要考虑的问题。此外，容器管理平台还要实现服务的注册和服务的发现、微服务版本的管理和微服务的升级与降级等，这个过程需要考虑到灰度发布策略和已有会话的处理等工作。当然，这只
是一部分例子，除此之外还会涉及到生命周期管理、团队协作和应用配置管理等各个方面的功能点。
面向微服务的容器网络和存储实现架构讨论
接下来和大家分享一下使用容器进行微服务支撑的另外两个技术挑战点：
第一个挑战是微服务模式下如何使用容器网络。
大家关注容器技术，知道容器的网络发展速度很快，比如 CNI、CNM 等各类网络模型出现。在谈容器网络的时候，大家很容易会陷入一个误区，即过度追求技术的时尚性，例如
Overlay , SDN 等等，这些技术与容器配合当然是未来的方向，但今天考虑把容器技术真正落地，隧道网络不一定适合每个企业。很多企业既希望容器像虚拟机一样直接使用业务
IP ，又不希望 IP 资源过渡消耗。因此产品设计要关注用户的实际使用需求。
第二个挑战是微服务模式下的容器存储方案。
一个大的系统，不同的微服务模块，对包括存储、计算、网络都有不同的 SLA 要求，譬如做数据处理的模块与做图片归档的模块对存储要求是不一样的。是不是有一天我们定义应用对接存储的规格时，可以通过写一行配置参数，不同的存储指向和
SLA ，比如数据处理模块对接到跨多主机 SSD 盘阵的分布式存储上，图片归档可能是放在 SATA 盘阵或是公有云存储，比如七牛云上呢？这可能是未来支持微服务的平台必须具备的功能之一。
刚才提到，微服务时代似乎确实需要极强的容器管理平台，帮我们更好的管理微服务。而这样一个平台需要考虑到多方面功能点，以下是一些成熟的容器管理平台要解决的问题。
在产品设计上，我们在思考有没有好的方式，能够根据用户量访问情况做到对微服务模块的自动扩容( AutoScale
)，这也是大家比较关心的问题。否则花了很大力气改造微服务，做完后却发现这个平台不具备根据用户的访问自动扩展服务的能力，微服务的价值也大打折扣。
微服务容器化下的安全架构考虑
每个企业都会关心信息安全。上了容器后，大家也会关心如何解决容器环境下的安全挑战。
传统的模式不太适用于新的容器时代或者微服务时代。大家想象一个场景，以前虚拟机时代，数量是有限的，对于一个企业来说，虚拟机有几百台，还是采用手动管理安全策略。现在容器数量可能一万甚至十万个，容器的创建和删减完全由系统自动决定。传统的人工策略已然不适用，因此需要新的能够适应未来容器时代和微服务时代的安全模型。
有容云的容器安全产品设计，是以应用为中心的角度考虑容器时代的安全挑战。比如整个微服务拓扑的可见度，我们能不能把容器之间的通讯完全呈现出来，让大家直观看到哪些微服务模块之间存在数据通讯及其质量。当你的一个内部微服务模块突然之间开始将大量数据发送到互联网，你需要得到一个告警，并去处理，看看是不是被黑客攻击了。还有诸如容器漏洞热补丁以及镜像扫描等功能，都是从容器安全角度考虑要去解决的问题。
微服务的日志聚合设计
传统时代，我们的日志不大会直接打印到标准输出，而一般会由团队达成一致，存于某个指定目录。
在微服务架构下，大家知道容器的玩法，对于日志收集，推荐的做法是将容器内微服务产生的日志打印到标准输出，然后通过外部收集器统一收集、处理和分析。有容云的产品可以把微服务模块日志全部集中处理。有可能一些传统组件没有办法把日志输出到标准输出，还是放在目录下的日志文件里，这时我们需要一个手段将其储存。当然有很多技术可以选择，我们的产品采用的是“日志处理伙伴容器”和“数据卷共享”技术，这种方式不是侵入式的，无需在微服务容器内注入其它组件。
私有镜像服务在 DevOps 环境的选择
在容器镜像管理中，需要对镜像权限进行管理。举个例子，镜像可以被自动化的流水线自动生成，放入镜像库的“开发”库(对应有容云AppHouse中的一个Project)时，镜像只是产生了，并未经过测试。如果运营人员一不小心把这样的镜像从镜像库拉下来，将对生产造成很大的影响。
对于我们来说，关注点在于如何将镜像和 DevOps 开发流程进行匹配。比如镜像进入开发库，只有测试人员才有权限进行测试。测试通过后，版本经理一定要做一个审批通过的动作，这样容器镜像才能在生产、运营中看到，才可以有权限把它拉进来。这是镜像设计仓库方面的一些考虑，相信我们未来在市面上会看到功能越来越丰富的产品。
容器驱动的轻量级 PaaS 解决方案架构示例
如果用容器驱动微服务开发，是不是需要有一个 PaaS 平台直接对整个开发项目的生命周期进行管理？其实
PaaS 是很多企业，包括前文提到的传统金融行业，很关注的解决方案。新的 PaaS 时代，大家更关注的问题是容器驱动的
PaaS 如何去做。大家可以想象一下，未来市场上会看到这样一些 PaaS 产品，你只要注册一个账号就能登录到这个
PaaS 平台，在上面你可以定义整个项目的生命周期，可以管理你的 Bug，管理你的项目，也可以完成协作等等。
通过灵活扩展、可配置的方式实现微服务应用商店模型
图中可能有大家熟悉的软件。在这样的平台上，我们是不是能够很容易获得这样的微服务模块？比如，需要形成大数据处理的能力时，它是不是唾手可得，不需要自己去开发？我们是不是可以形成基于微服务模块交易的市场？
大数据处理中有一个很大的难点，数据专家和业务专家中间有一个很大的鸿沟，比如说医疗数据如何建模、如何写逻辑等等，这方面我们是不是可以通过一种插件的模式，把医疗专家的经验通过数据处理模块进行封装，并通过一定形式进行分享。我想这些都是潜在的发展模式。也许未来，我们会看到蓬勃发展的微服务模块的交易市场。以上是我今天分享的内容，谢谢大家！
|
