随着市场的快速发展,业务的不断扩大,传统的单体应用架构面临着越来越多的挑战。微服务架构 (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 弹性容器服务》