IT老齐架构300讲笔记(060) 分布式架构开发时N点血的教训

IT老齐架构300讲笔记(060) 分布式架构开发时N点血的教训

目录

一、什么是分布式架构?

二、分布式开发各个方面分析

2.1 网络

2.2 性能

2.3 运维成本

2.4 组织架构层面

2.5 集成测试

三、微服务最佳实践

3.1 微服务的划分原则

3.2 微服务实践通用原则

3.3 为每一个微服务模块明确使命

3.4 微服务确保独立的数据存储

3.5 服务间通信优先采用聚合器模式

3.6 一定要务实，不要强行“微服务”化

专栏链接: IT老齐架构300讲笔记

---

一、什么是分布式架构?

分布式系统是将一个大的系统打散成很多个小系统、小服务，再由多个团队协作完成共同的目标。

更小的管理粒度独立的数据存储统一的通信标准

二、分布式开发各个方面分析

从网络、性能、运维成本、组织架构与集成测试五个方面分别进行阐述

2.1 网络

以往单体应用是在单机中进行进程内通信，通信稳定性相当好。但是打散为分布式系统后，变为进程间通信，往往这个过程还伴随着跨设备的网络访问，架构师在设计时必须考虑上下游系统因为网络因素无法通信的情况，要假设网络是不可靠的，并设计微服务在网络异常时也能进行符合预期的异常处理。以支付模块为例，用户支付成功后系统自动调用短信服务向用户手机发送“订单支付成功”的消息，此时架构师就必须假设短信服务在服务或者网络不可用时不会影响到订单业务的正常执行。

2.2 性能

传统单体架构进程内通信，跨进程、跨网络的微服务通信在网络传输与消息序列化带来的延迟是不可被忽略的，尤其是在五个以上微服务间消息调用时，因为网络延迟对于实时系统的影响是是很大的。早些年我和一个军事院校合作了一个雷达仿真训练的系 统，因为要模拟"导d打飞机"的场景，在计算飞行轨道时1毫秒的响应增加都可以会影响到 最终的结果，显然这类系统采用分布式设计就不再合适。

2.3 运维成本

运维成本会直线上升，早期单体应用因为结构简单，规模也较小，发版时通常面对几台服务器部署几个Jar/War文件就可以了。同时，应用的交付周期也是以周甚至月为单位，此时硬件设备成本与运维人员技术要求都比较低，采用手动部署即可满足要求。而对于微服务架构而言，每一个服务都是可独立运行、独立部署、独立维护的业务单元，再加上 互联网时代用户需求的不断变化以及市场的不稳定因素，运维人员每天面对成百上千台服务器发布几十次已是家常便饭，传统手动部署显然已经无法满足互联网的快速变化。

2.4 组织架构层面

微服务不但是一种架构风格，同样也是一种软件组织模型，以往软件公司会按照职能划分，如:研发、测试、运维部门进行独立管理考核，而在微服务的实施过程中，以业务模块进行划分团队，每一个团队是内聚的，要求可以独立完成从调研到发版的全流程，尽量减少对外界的依赖。

 2.5 集成测试

传统单体架构集成测试是将不同的模块按业务流程进行组合，在进程内验证每一种可能性下其模块间协作是否符合预期即可。微服务而言，系统被拆解为很多独立运行的单元，服务件采用接口进行网络通信。要获取准确的测试结果，必须搭建完整的微服务环境，光这一项工作就有很大的工作量。同时，因为是跨网络通信，网络延迟、超时、带宽、数据量等因素都将影响最终结果，测试结果易产生偏差。

三、微服务最佳实践 3.1 微服务的划分原则

微服务的划分原则。将已有系统拆分为多个微服务，本就没有统一的标准。举个例子，一个初创型电商公司，要开发一套电商系统，将“促销活动”单独剥离出来作 为"促销服务"是没有问题的. 但是如果你在“淘宝”、“京东”这种体量的电商平台，"促销 服务"就显得粒度太粗，可以继续拆解为"价格服务"、"优惠券服务"、“京豆服务”等更细粒度的小服务，每个服务有专门团队负责维护。

3.2 微服务实践通用原则

单一职责原则，每一个微服务只做好一件事，体现出“高内聚、低耦合”，尽量减少对外界环境的依赖。比如，在公司创业之初，完全可将订单与仓储服务进行合并。因为订单与仓储在业务与数据紧密相关，如果强行拆分会导致出现跨进程通信带来的数据一致性难题。随着业务的发展，仓储的业务职责扩展，派生出许多与订单无紧密联系的功能，到时再将其剥离形成独立的“仓储服务”也不晚。

 服务依赖原则，避免服务间的循环引用，在设计时就要对服务进行分级，例如区分核心服务与非核心服务。例如订单服务与短信服务，显然短信服务是非核心服务，服务间调用要遵循“核心服务”到“非核心服务”，不允许出现反向调用。同时，对于核心服务要做好保护，避免非核心服务出现问题影响核心服务的正常运行。

Two Pizza原则，就是说让团队保持在两个比萨能让队员吃饱的小规模的概念。团队要小到让每个成员都能做出显著的贡献，并且相互依赖，有共同目标，以及统一的成功标准。一个微服务团队应涵盖从需求到发布运维的完整生命周期，使团队内部便可以解决大部分任务，从人数上4~6人是比较理想的规模。 

3.3 为每一个微服务模块明确使命

推荐一套标准的微服务叙述模板，集中体现“只做好一件事”的原则

模板
XX微服务用来
在出现痛点场景的情况下
解决现有的XX问题
从而达到了XXX的效果
提升了微服的价值
==============================================

示例
商品检索微服务用例
在商品数据全量多维度组合查询的情况下
解决了MySQL数据库全表扫描查询慢的问题
从而让查询响应降低到50ms以下
有效提升了用户体验

3.4 微服务确保独立的数据存储

数据是任何系统最重要的资产。以往单体应用通常会选择MySQL这种关系型数据库作为数据的统一存储，这样做的好处是涉及多表 *** 作时,利用数据库自带的事务机制便可最大程度保证数据完整性。但这样做却存在诸多问题,如果将所有数据都揉在MySQL 中使用会变得十分蹩脚，好的做法是为每一个微服务提供符合自身业务特性的数据库。

 

在分库后涉及到跨库 *** 作会变难以处理。比如，订单依赖会员数据，原始单库处理时一条SQL语句便可实现。但在微服务架构下，因为数据库绝不允许其他团队访问，关联查询只能变为API调用形式，程序实现层面比单库复杂不少。

3.5 服务间通信优先采用聚合器模式

在微服务间通信时存在两种消息传递模式“链式模式”与“聚合器模式”。下图是所示，按业务流程请求在各个服务间流转，最终处理完成返回客户端。

因为请求是按业务流程传递，很容易能被开发人员理解，因此链式模式称为了最常用的 服务间通信模式。但链式模式采用串联模式，调用整个成功率等于服务调用成功率的乘积。在服务处理完成前请求会一直处于阻塞状态，当调用链较长时，系统整体性能会严重下滑。

聚合器模式则是通过服务作为入口，组装其他服务的调用，因为“订单流程服务”是将其他服务进行聚合 *** 作，所以称其为聚合器模式。以“订单流程服务”为例，将“订单”、“支付”、“库存”服务进行聚合，一个服务实现从下单、支付、减库存的完整流程。

3.6 一定要务实，不要强行“微服务”化

适合微服务化的场景

新规划的大型业务系统

敏捷的小团队系统，"试验田"

历史的大型留存业务系统

 不适合微服务化的场景

微型项目 系统压力很小，需求变化也不大

对数据响应要求高的系统