基于Docker容器的微服务架构实践

随着市场的快速发展,业务的不断扩大,传统的单体应用架构面临着越来越多的挑战。 微服务架构(Microservices Architecture) 的诞生,对软件架构领域所带来的影响毋庸置疑。

为什么微服务架构比单体应用架构,在研发过程中更加敏捷和灵活呢?先从单体应用的架构说起。下图是一个比较经典的单体应用架构,来自Chris Richardson的《微服务系列》:

比较经典的单体应用架构

上图表示一款与滴滴或者Uber竞争的打车软件,这款新应用采用了传统的六边形架构模式。 根据不同的功能需求,分成了多个不同的模块。各个模块之间直接通过API调用,互相协同工作。

由于IDE擅长构建单体应用,采用这种架构的应用非常普遍。这类应用也可以很轻松下断点测试。单体应用也便于部署,只需将软件包复制到服务器,简单配置后即可良好运行。在项目早期这么做非常有效。

但当几年过去了, 随着功能的扩展,项目就变得臃肿,不够灵活。 同时,开发者必须对整个应用的架构和模块,有一定程度的了解,才可能对它进行修改。而且 项目可靠性差,难以持续开发、部署,扩展困难。

典型的打车软件微服务架构图

不同于单体应用,微服务架构将各个功能模块拆分成独立的服务,服务与服务之间通过REST API交流。不同的服务有自己的功能、数据库和REST API。

这种微服务架构有什么特点呢?

1. 业务功能驱动设计:不同的功能做成不同的服务,例如根据用户界面、用户管理、司机界面、司机管理、账单管理、账单支付等不同的功能,做成不同的服务;

2. 单一职责原则:每一个服务,它的功能应该都是单一的,如果有多个功能,则做成多个服务为宜,例如用户界面和用户管理就分成单独的服务;

3. 明确发布接口:接口一旦发布了,就不要轻易更改,因为更改了很可能会导致所有服务都要进行相应的更改,服务的消费者也只需要关心接口,无需关心服务的内部实现;

4. 轻量级通信:服务与服务之间,通过简单的、轻量级的通讯协议交流即可,例如,同步的REST,异步的AMQP、STOMP、MQTT等;

5. 可以异构/采用多种语言栈:每个服务的实现细节都与其它服务无关,这使得服务之间能够解耦,团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法;

6. 独立部署、升级、扩展和替换:每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级,扩展和替换;

对应的,微服务架构有如下的优点:

1. 复杂度可控,易于开发、理解和维护;

2. 局部修改很容易部署,有利于持续集成和持续交付;

3. 故障隔离,一个服务出现问题不会影响整个应用;

4. 弹性伸缩、扩展方便,根据需求分配不同的资源;

5. 技术选型灵活,可以根据需求选择合适的技术;

同时,微服务架构也有着它的缺点:

1. 数据一致性难以保证;

2. 分布式调用造成的性能、延迟和可靠性问题;

3. 不同服务之间的依赖问题,导致复杂度增加;

4. 部署复杂,配置、部署、扩展和监控难度大;

目前,很多服务都是单体应用架构,  这些老的应用该如何过渡到微服务架构呢?  一般来说,都是采取以下的方式:

1. 为新功能特性创建微服务,原有的单体应用保持不变或仅做必要的修改;

2. 根据业务功能各自剥离为微服务;

3. 按照业务功能价值和需要安排优先级;

4. 不追求完全消灭单体应用;

Docker的诞生

在单体应用越来越难以满足人们需要的时候,Docker诞生了。作为一个在最近这几年异军突起的技术,仿佛就是为了微服务架构而生。 每个Docker容器,只运行一个微服务。 从此,开发人员摆脱了单体应用架构带来的负担,使每天都更新线上项目不再是一个梦想。

Docker容器,是类似JVM但比其更强大的容器,基于Linux内核。支持各种语言。它比VM虚拟机更加轻量,能够在云计算IaaS等平台上直接运行,使用户的应用无缝地移植到各种运行环境。

一般来说, Docker容器服务也叫弹性容器服务(ECS),或者容器云 。在Docker越来越火的今天,在国内外都有很多提供弹性容器服务的提供商。例如国外的亚马逊、Tutum云和CoreOS,国内的DaoCloud、网易蜂巢、时速云和灵雀云等等。

如果要使用弹性容器服务,则必须从开发阶段开始,以微服务架构的形式开发应用,或者对现有的单体应用进行解耦。

开发、测试、部署流程示意图

开发、测试、部署 流程简介:

1. 运维人员在ECS上搭建私有Docker Registry;

2. 开发人员在开发ECS上从DockerHub或私有DockerRegistry获取应用需要的基础镜像;

3. 开发人员开发ECS上构造应用容器,自测后提交容器为新的镜像并推送到私有Docker Registry,通知QA测试;

4. QA在自己的测试ECS上启动容器,测试后,有问题则a,没问题则b:

a. 通知开发修复,回到步骤3;

b. 提交到私有Docker Registry,准备发布;

5. 发布人员下载最新版本镜像并在生产ECS上启动容器。

最后再说一下,Docker弹性容器服务的关键点:

1.服务注册、发现:容器很容易创建,也非常容易被销毁,新创建的容器需要能够自动注册,并被其它服务发现。

2. 跨主机网络:容器只会暴露必要的端口,不同物理主机之间的容器服务交换数据,一般都是通过单独的、私有的网络进行交互。

3. 存储服务:容器是无状态的,即容器是不能,也不必要保存任何的数据,所以一般都是通过网络储存服务,例如S3,进行数据存储。

4. 健康检查:一般的微服务架构应用,会运行很多个容器,对这些容器的状态进行健康检查是很有必要的。不健康的容器会被销毁,然后再启动一个新的容器替代。

5. 自动弹性伸缩:时刻检测容器的资源情况,当某个服务访问量增大,资源消耗增多时,可能导致服务无法访问时,可以自动增加同一个服务的容器,达到动态平衡。

6. 监控日志:容器随时可能因为出错而被销毁,销毁后无法像普通虚拟机那样查看日志,所以一个良好的日志收集是必须的。

7. 资源隔离:目前容器的隔离性还无法做到普通VM那样的程度,所以在弹性容器服务里,一般会把容器跑在VM里,尽管性能和直接跑在物理机上没法比,但容器还是拥有启动快,开销小的特点。

8. 灰度升级:当应用上线后,服务是无法同时全部关机更新的。而灰度更新,可以逐步分批更新服务,达到无缝更新的效果。

9. 私有仓库:对企业来说,应用的镜像保存在私有的仓库中更适合,而不是分享到Docker官方源,同时私有仓库可以搭建在内网,速度快。

文章标签: docker 容器 微服务 架构


关注微信公众号“架构说”,加入Q群微群,让架构师带你飞︿( ̄︶ ̄)︿。


原文链接: 阅读原文
免责申明: 架构说任何转载的文章都会明确标注原文链接。如有侵权,请与本站联系。
转载说明: 架构说原创文章转载时请务必注明文章作者、链接和来源。