品高公开课 | 基于Docker容器的微服务架构实践

小编的话

“品高公开课”系列文章意在分享技术牛人的知识干货，每期主题都不一样哟！期待各位读者在文后发表留言，来一场技术上的交流和思想上的碰撞！

微服务以一种全新的架构设计模式，牵动了互联网应用从设计到运维整个流程方法论的变革。 而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制。本周五，将由品高软件工程师陈洪杰带讲述微服务架构的故事。

分享嘉宾

陈洪杰，目前就任品高广州云架构产品部--BingoCloud平台的软件开发工程师，拥有Docker，LXC等多个容器平台的项目经验，15年开始转向弹性容器服务（ECS)的研究，主要负责弹性容器服务的规划、设计和开发。

分享正文

▼

随着市场的快速发展，业务的不断扩大，传统的单体应用架构面临着越来越多的挑战。微服务架构(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官方源，同时私有仓库可以搭建在内网，速度快。

====================================分割线================================

本文转自d1net（转载）