1. 背景
本文是我在学习 Spring Cloud 构建微服务的过程中记录学习心得。
2. 什么是微服务
微服务是系统架构上的一种设计风格， 它是将一个原本独立的系统 拆分成多个小的互相通信的服务。
特点
- 将一个独立的系统 拆分成多个小型服务，拆分后的各个服务都在各自独立的进程中运行.
- 各个服务之间通过基于HTTP 的RESTful API进行通信协作。
- 被拆分成的每一个小型服务都围绕着系统中的某一项耦合度较高的业务功能进行构建
- 每个服务都维护着自身的数据存储、 业务开发、 自动化测试，及独立部署机制。
微服务和单体系统的区别
| 维度 | 单体系统 | 微服务 |
|---|---|---|
| 分层： | 一般是前端展现， 服务端处 理，数据库 | 每个微服务都有各自的分层，可能不相同。可能采用不同的开发语言，模式进行开发。 |
| 模块间依赖方式： | 代码依赖。模块见函数调用。 | 服务间的通信依赖。 比如HTTP 方式通信。 |
| 业务发展初期： | 开发、 测试、 部署 都比较方便 | 直接一整套全家桶，需要更多准备 |
| 业务模块持续膨胀： | 模块耦合严重，改动可能影响其他功能。 越来越腕肿。模块资源互相影响。不同模块消耗资源难以评估。 | 适度调整业务拆分，适合于不断演进。 |
| 前端形式增多，比如App，微信小程序 | 难以同时应对多种前端 | 更多支持 |
| 维护成本： | 维护成本会变得越来越大 | 不断扩展 |
| 部署角度： | 每次改动都要整体部署。 | 每个服 务的更新部署不会影响其他服务的运行。 每个服务都运行在自己的进程内， 在部署上有稳固的边界 |
| 对运维人员的要求： | 部署工作较少。 对运维人员能力要求不高。 | 需要更多的运维人员和工作。 运维过程需要 更多的自动化。 |
| 分布式的复杂性： | 无 | 各个微服务都是运行在各自的进程内，他们之间通过通信来进行协作。 带来难题：网络延迟、 分布式事务、 异步消息 |
| 团队规模： | 适用于人数不多的小团队。 | 适用于人数多的团队，可以按模块划分团队。 |
微服务架构的九大特性， 用于指导大家设计架构
- 1）服务组件化
- 2）按业务组织团队
- 3）做“产品” 的态度
- 4）智能端点与哑管道
- 5）去中心化治理
- 6）去中心化管理数据
- 7）基础设施自动化
- 8）容错设计
- 9）演进式设计
服务组件化: 服务，是一种进程外的组件,它 通过 HTTP 等通信协议进行协作,每一个 服务都独立开发、 部署， 可以有效避免一个服务的修改引起整个系统的重新部署。
按业务组织团队: 大型项目时， 对于微服务团队的拆分更加建议按业 务线的方式进行拆分， 既有效减少服务内部修改所产生的内耗; 另 一方面， 团队边界更清晰
做“产品” 的态度：团队用做 “产品” 的态度来对待每一个微服务， 持续关注服务的运作情况， 并不断分析和改善业务功能。而不是以项目的模式，以完成开发并将成果交接给维护者为最终目标。
智能端点与哑管道： 区别于单体系统采用函数调用的方式进行交互协作，在微服务架构中， 采用的服务调用方式有：（1）使用HTTP的RESTfulAPI进行信息传递与服务调用。（2）在轻量级消息总线上传递消息， 类似 RabbitMQ 等 一些提供可靠异步交换的中间件。（3）极度强调性能的情况下，会使用二进制的消息发送协议， 例如 protobuf。
去中心化治理：在采用集中化的架构治理方案时，一般是统一的技术平台标准， 在遇到该技术平台短板时， 不得不花费大力气去解决， 而受限于其底层原因可能成为系统的瓶颈。而微服务架构时， 通过采用轻量级的契约定义接口，这样各个组件就能
针对其不同的业务特点选择不同的技术平台。
去中心化管理数据: 在实施微服务架构时， 都希望让每一个服务来管理其自有的数据库， 这就是数据管理的去中心化。数据一致性也成 为微服务架构中亟待解决的问题之一。
基础设施自动化：在微服务架构中， 务必从一开始就构建起 “ 待续交付” 平台来支撑整个实施过 程。需要两大内容：
自动化测试和自动化部署。
容错设计: 在微服务架构中， 各个服务都运行在独立的进程中， 所以存在部分服务出现故障， 而其他服务正常运行的情况。所以， 在微服务架构中， 快速检测出故障源并尽可能地自动恢复服务是必须要考虑的。我们都希望在每个服务中实现监控和日志记录的组件， 比如服务状态、 断路器状态、 吞吐量 、 网络延迟等关键数据的仪表盘等。
演进式设计：随着系统的发展或者业务的需要， 架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理， 并逐渐将原来 在单体系统中多变的模块逐步拆分出来， 而稳定不太变化的模块就形成一 个核心微服务存 在于整个架构之中。
网友评论