万网有网站建设吗,网站优化北京哪家强?,wordpress 多条件,常德规划建设局网站尽管微服务架构有着高度独立的软件模块、单一的业务职责、可灵活调整的技术栈等优势#xff0c;但也不能忽略它所带来的弊端。本篇文章#xff0c;我们从网络、性能、运维、组织架构和集成测试五个方面来聊一下设计微服务架构需要考虑哪些问题#xff0c;对设计有哪些挑战呢…尽管微服务架构有着高度独立的软件模块、单一的业务职责、可灵活调整的技术栈等优势但也不能忽略它所带来的弊端。本篇文章我们从网络、性能、运维、组织架构和集成测试五个方面来聊一下设计微服务架构需要考虑哪些问题对设计有哪些挑战呢
1、跨进程通信带来的问题
前面我们聊过了以往的单体应用系统是在单机中进行进程通信通信的稳定性相当好只要服务器不宕机基本上不会出现通信中断或异常的问题超时不计入。但是将单体应用打散为分布式架构后系统的通信方式改变为了进程间通信往往还有可能伴随着跨设备的网络访问那么架构师在设计的时候就必须要考虑应用的上下游系统因网络因素导致无法通信的问题。要假设网络是不可靠的就相当于是前端页面不应该相信用户的一切输入该做的数据校验一定要做并对网络异常情况作出符合预期的异常处理。 以支付场景为例用户支付成功后系统自动调用短信发送服务给用户发送支付成功的短信此时就需要考虑到如果短信发送不成功需要做什么异常处理。是标记未发送后重试还是通过App进行消息提示并将异常信息入库提醒运维检查短信服务运行情况。 单体应用调用链路 微服务架构下的调用链路 2、响应延迟带来的问题
与单体架构进程内通行相比微服务架构的跨进程、跨网络通信在网络传输与消息序列化带来的延迟是不可忽略的。尤其是在五个以上的微服务间消息调用时网络延迟对于实时系统的影响是很大的。 以红海行动电影中的1130近防炮的弹道计算为例需要通过雷达监测的敌方炮弹的射速、方位、风速等因素计算近防炮在何时、哪些方位发射子弹进行拦截。在这种情况下使用微服务架构带来的延迟可能导致炮弹都打到身上了弹道计算数据还没传过来。显然这类系统采用分布式设计就不合适。 以上例子纯属军事外行瞎猜只是为了举例说的不对的还请不要介意。。 3、运维方面的问题
之前的单体架构运维在部署系统时直接将系统jar或war包丢到容器里启动就行了就算是没有自动化部署工作量也不是很大。同时以前的系统升级都是以周或月为单位就算是人肉运维也都可以应付得过来。而对于微服务而言每个服务都是可独立运行、独立部署、独立维护的业务单元。再加上市场的需求越来越高运维人员每天面对成百上千台服务器发布几十次都是有可能的人肉运维和部署显然已经无法满足互联网的快速变化。 自动化运维架构图
4、组织架构带来的问题
微服务架构带来的不仅是软件架构的改变也是公司组织架构的改变。
单体架构下公司以职能划分部门项目部、产品部、设计部、开发部、测试部、运维部进行独立管理考核技术人员负责其中的某几个模块开发即可可由统一的项目经理、产品经理、UI设计师进行支撑。
微服务架构下是以业务模块进行团队划分每个团队是内聚的要求可以完成从调研到发版的全流程尽量减少对外界的依赖。如何将之前的职能团队调整为按业务划分的研发团队同样是对组织架构的巨大挑战。毕竟人的思想比架构更难改变。 单体架构下团队配置 微服务架构下团队配置 5、集成测试变得异常艰难
传统的单体架构集成测试是将不同的模块按业务流程进行组合在进程内验证每种可能性下模块间的协作是否符合预期即可。对于微服务而言系统被拆解成独立的运行单元服务间采用接口进行通信。要获取准确的结果必须搭建完整的微服务环境。同时跨网络通信带来的网络延迟、超时、带宽、数据量等因素都将影响最终结果测试结果容易产生偏差。 所以微服务架构并不是没有缺点在一定程度上可能造成的影响比单体的影响大很多。那么我们是难道就不进行改造吗有困难就退缩不是一个优秀架构师该有的品质。那有什么可借鉴的经验吗当然有我们以后再下篇接着聊
