尽管微服务架构有着高度独立的软件模块、单一的业务职责、可灵活调整的技术栈等优势，但也不能忽略它所带来的弊端。本篇文章，我们从网络、性能、运维、组织架构和集成测试五个方面来聊一下设计微服务架构需要考虑哪些问题，对设计有哪些挑战呢？

1、跨进程通信带来的问题

前面我们聊过了，以往的单体应用，系统是在单机中进行进程通信，通信的稳定性相当好，只要服务器不宕机，基本上不会出现通信中断或异常的问题（超时不计入）。但是将单体应用打散为分布式架构后，系统的通信方式改变为了进程间通信，往往还有可能伴随着跨设备的网络访问，那么架构师在设计的时候，就必须要考虑应用的上下游系统因网络因素导致无法通信的问题。要假设网络是不可靠的（就相当于是前端页面不应该相信用户的一切输入，该做的数据校验一定要做），并对网络异常情况作出符合预期的异常处理。

以支付场景为例：用户支付成功后，系统自动调用短信发送服务给用户发送支付成功的短信，此时就需要考虑到如果短信发送不成功需要做什么异常处理。是标记未发送后重试，还是通过App进行消息提示，并将异常信息入库提醒运维检查短信服务运行情况。

单体应用调用链路：

微服务架构下的调用链路：

2、响应延迟带来的问题

与单体架构进程内通行相比，微服务架构的跨进程、跨网络通信在网络传输与消息序列化带来的延迟是不可忽略的。尤其是在五个以上的微服务间消息调用时，网络延迟对于实时系统的影响是很大的。

以红海行动电影中的1130近防炮的弹道计算为例：需要通过雷达监测的敌方炮弹的射速、方位、风速等因素计算近防炮在何时、哪些方位发射子弹进行拦截。在这种情况下，使用微服务架构带来的延迟，可能导致炮弹都打到身上了，弹道计算数据还没传过来。显然这类系统采用分布式设计就不合适。 以上例子纯属军事外行瞎猜，只是为了举例，说的不对的还请不要介意。。

3、运维方面的问题

之前的单体架构，运维在部署系统时，直接将系统jar或war包丢到容器里启动就行了，就算是没有自动化部署，工作量也不是很大。同时，以前的系统升级都是以周或月为单位，就算是人肉运维也都可以应付得过来。而对于微服务而言，每个服务都是可独立运行、独立部署、独立维护的业务单元。再加上市场的需求越来越高，运维人员每天面对成百上千台服务器发布几十次都是有可能的，人肉运维和部署显然已经无法满足互联网的快速变化。

自动化运维架构图

4、组织架构带来的问题

微服务架构带来的不仅是软件架构的改变，也是公司组织架构的改变。

单体架构下，公司以职能划分部门（项目部、产品部、设计部、开发部、测试部、运维部）进行独立管理考核，技术人员负责其中的某几个模块开发即可，可由统一的项目经理、产品经理、UI设计师进行支撑。

微服务架构下，是以业务模块进行团队划分，每个团队是内聚的，要求可以完成从调研到发版的全流程，尽量减少对外界的依赖。如何将之前的职能团队调整为按业务划分的研发团队，同样是对组织架构的巨大挑战。毕竟人的思想比架构更难改变。

单体架构下团队配置

微服务架构下团队配置

5、集成测试变得异常艰难

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

所以，微服务架构并不是没有缺点，在一定程度上，可能造成的影响比单体的影响大很多。那么我们是难道就不进行改造吗？有困难就退缩不是一个优秀架构师该有的品质。那有什么可借鉴的经验吗？当然有，我们以后再下篇接着聊！