微服务设计模式与容器云平台

什么是微服务，用Martin Fowler的一段话：没有一个明确的定义，但简单来说是，以一组小型服务来构建成应用，每个服务运行在单一独立的进程，不同服务间采用轻量级的交互机制来通信，例如HTTP(REST API)。这些组成应用的服务围绕业务能力来构建，完全采用自动化部署方式，可独立部署扩展，不同的服务可以采用不同的编程语言来实现，由独立的团队来维护。

实际上多年前的所谓的SOA面向服务架构，现在的微服务架构依然是SOA的一种思想实现。微服务的特点还是显而易见的，组件化，独立部署，传统实现组件的方式是通过库（library）,C++ java通过静态或动态链接构建成软件，不强调进程分化，升级时需要整体重新部署或服务重启。但微服务的方式把他们各部分拆分了，变成一系列服务以进程的粒度运行，意义就在于，升级部署时，只需局部更新过时组件，而不需要牵动整个系统。当然这种跨进程的调用方式需要考虑边界问题，也就是各组件的容错性，在设计之初需要考虑各部分明确职责。

容器技术的逐步成熟给DevOps带来了一场变革，也给微服务思想的实现提供了便利。当我们讨论容器技术的优势时，通常会提到轻量级、快速部署、迁移方便等，这些优势大大方便了应用的测试、部署和升级，而很少提到开发。DevOps的目标是整合产品开发、测试、部署和维护，保证产品的性能和稳定性，同时加快新功能的开发和上线。借助于容器技术和微服务架构，开发真正融入到产品交付流程中。

我们不妨考虑下面几个问题：1. 服务升级是否频繁，单次耗时情况怎样，升级时能否提供不间断的服务；新版本的应用意外崩溃，打热补丁的时间，服务是否会中断；2. 新增feature时，是否需要整体重新部署或者重启核心服务，是否需要重新测试已有功能，服务是否会中断；3. 出现故障的原因，多少是因为程序本身的bug，多少是因为部署/升级时的人为疏忽或者沟通不畅；4. 随着用户的增长，关键组件（服务）是否能够水平扩展。如果考虑系统升级频率较高以及希望热升级避免服务间断，而且面临上面提到的问题的话，微服务架构很可能是个不错的选择。

传统上，软件的架构是自上而下瀑布模式，模块间耦合分离采用调用库链接方式，一部分原因是主流的编程语言（C/C++、 Java 等）是过程式或面向对象式的，便于实现流线型的程序。微服务提倡的是便于横向扩展的应用，对内，一组微服务是相互独立的进程，通过轻量级的协议交互，可能使用不同的编程语言实现；对外，一组微服务作为一个应用为用户提供不间断的服务。下面我们介绍几个微服务设计模式，看看容器技术和微服务在生产中的应用。

1.Ambassador 模式（大使）

通常情况下，不同的服务会有一定的耦合，比如说nodejs web应用和 redis 服务、php web应用。我们以web服务和redis服务为例，来重现下可能的问题。

主服务要访问redis服务，所以必须知道redis是如何部署的。redis发生变化时，原先访问redis的方式通常会失效，这时候我们不得不重新修改主服务。但主服务代码中可能包含大量的业务逻辑，访问redis的代码散落在各个角落，给下次升级留下了很多潜在bug。如果把访问redis的代码从web主服务中剥离出来，放到一个单独的容器里，即 (web app)-> (Ambassador: redis proxy) -> (redis server)，我们就不需要频繁修改web app了。

2.SideCar模式（伴随者）

使用SideCar模式，我们可以从外围对核心服务做一些增强工作。比如，在部署主服务容器时，同时部署一个用于日志搜集的应用容器，定时搜集并发送日志到日志服务器；或者监控服务容器，用以监控主服务的运行状态。主服务实例过多时，可以部署一个git同步服务容器，无需人工干预就可以定时更新服务器上的代码。

3.Adaptor模式（适配器）

这个模式主要是将应用适配到不同的环境中。例如，为跨云端的应用部署统一的监控系统，假如应用部署在AWS、阿里云等多个IaaS上，监控系统为了获取日志等信息可能需要针对每个IaaS厂商进行适配。

为了保证核心服务的稳定性和独立性，可以另外实现服务获取应用运行和运行环境信息，这个服务可以对不同IaaS的API进行适配。部署和升级时，主服务容器和监控服务容器同步创建和销毁。

实际上前面所举的模式需要在容器的技术基础上，平台具有弹性伸缩动态更新的功能，而例如像伴随者模式，这个服务伺服变动频繁，体量微小，最好能与主服务共享部分资源并且共存生命周期。这个在kubernetes的pod概念里有非常好的实现特性。

Kubernetes是集群级别的容器编排系统，是源于google的borg项目，它在构建应用时，物理和逻辑上构建了3个层次，即pod、replicationctroller、service。通过将一个或多个容器放入pod来实现最小调度单元，通过replicationctroller来实现pod的副本控制即弹性伸缩，service是逻辑概念，通过proxy的方式让多副本pod为上层服务提供负载均衡。Kubernetes本身支持多种网络类型，但自身并不解决多机集群的网络问题，还支持多种类型的分布式存储。

Kubernetes的Pod对微服务有先天的支持，Pod内的容器共享存储共享网络，这让处于微服务模式中的容器联系更加紧密。同时，控制器又可以对他们进行灵活的更新升级。比如Ambassador 模式，proxy的部分根据外部db的变化需要较频繁的更新，在k8 pod的内部与主服务是以localhost的方式通信，无需暴露到外部。 这样既可以充分利用Kubernetes在资源调度上的优势，也可以充分利用微服务的优势。Kubernetes中的Pod具有独立的IP，从这个角度来看，比容器更像一个虚拟机。将多个相关关联的容器应用部署在同一个Pod中，pod的生命周期由上层的调度机制决定，真正实现了松耦合、高可用和负载均衡。

在容器微服务方面，时速云支持 docker 本身的compose方式，支持多容器互联，只需要ymal格式以指定的组合对服务进行构建。同时利用控制器维持服务的可用性。

而利用主机产品，搭建私有的caas平台，将会具有更多的权限，支持较大数目的容器，未来会开通api，拥有对kubernetes更多的控制权限。