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

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


比较经典的单体应用架构

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

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

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

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

不同于单体应用,微服务架构将各个功能模块拆分成独立的服务,服务与服务之间通过 RESTAPI 交流。不同的服务有自己的功能、数据库和 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,国内的品高云 BingoCloudOS、daocloud、网易蜂巢和时速云等等。

各类提供弹性容器服务的云厂商

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

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

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

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

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

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

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

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

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

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

 

Docker 弹性容器服务的关键点

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

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

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

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

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

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

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

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

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

若想了解更多关于品高云 BingoCloudOS 弹性容器服务的相关信息,可参照博客内相关文章:《【深度解析 7.0 系列】01 弹性容器服务》