在分布式系统设计时N点血的教训，与君共勉！.pdf
免费下载
什么是分布式架构？分布式系统是将一个大的系统打散成很多个小系统、小服务，再
由多个团队协作完成共同的目标。现在以微服务架构为代表的分布式系统大行其道，至于微
服务的好处我在这就不多赘述，比如：更小的管理粒度、独立的数据存储、统一的通信标准
等等，今天咱们就聊一聊以微服务为代表的分布式系统设计时有哪些坑吧！
在著名软件著作《人月神话》中提到，软件世界没有“银弹”，这句话当然适用于架构
领域，随这从单体架构过度到微服务架构，因为将原有系统打散，给系统增加了许多不稳定
因素。
单体架构想微服务架构转变
下面我从网络、性能、运维成本、组织架构与集成测试五个方面分别进行阐述。
第一点，以往单体应用是在单机中进行进程内通信，通信稳定性相当好。但是打散为分
布式系统后，变为进程间通信，往往这个过程还伴随着跨设备的网络访问，架构师在设计时
必须考虑上下游系统因为网络因素无法通信的情况，要假设网络是不可靠的，并设计微服务
在网络异常时也能进行符合预期的异常处理。以支付模块为例，用户支付成功后系统自动调
用短信服务向用户手机发送“订单支付成功”的消息，此时架构师就必须假设短信服务在服
务或者网络不可用时不会影响到订单业务的正常执行。
微服务进程间RESTful通信
第二点，相比传统单体架构进程内通信，跨进程、跨网络的微服务通信在网络传输与消
息序列化带来的延迟是不可被忽略的，尤其是在五个以上微服务间消息调用时，因为网络延
迟对于实时系统的影响是是很大的。早些年我和一个军事院校合作了一个雷达仿真训练的系
统，因为要模拟"导弹打飞机"的场景，在计算飞行轨道时1毫秒的响应增加都可以会影响到
最终的结果，显然这类系统采用分布式设计就不再合适。
第三点，运维成本会直线上升，早期单体应用因为结构简单，规模也较小，发版时通常
面对几台服务器部署几个Jar/War文件就可以了。同时，应用的交付周期也是以周甚至月为
单位，此时硬件设备成本与运维人员技术要求都比较低，采用手动部署即可满足要求。而对
于微服务架构而言，每一个服务都是可独立运行、独立部署、独立维护的业务单元，再加上
互联网时代用户需求的不断变化以及市场的不稳定因素，运维人员每天面对成百上千台服务
器发布几十次已是家常便饭，传统手动部署显然已经无法满足互联网的快速变化。
第四点，组织架构层面的调整，微服务不但是一种架构风格，同样也是一种软件组织模
型，以往软件公司会按照职能划分，如：研发、测试、运维部门进行独立管理考核，而在微
服务的实施过程中，以业务模块进行划分团队，每一个团队是内聚的，要求可以独立完成从
调研到发版的全流程，尽量减少对外界的依赖。如何将传统的职能团队调整为按业务划分组
织架构，同样是对管理者的巨大挑战，要知道人的思想比架构更难改变。
of 8
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论