认识达内从这里开始

认真做教育专心促就业

南宁达内IT培训微服务架构拆分原则与稳定性保障分析

发布：南宁达内it培训
来源：互联网
时间：2022-09-06 09:32

微服务架构开发技术的应用是大多数Java编程开发程序员都需要掌握的一个计算机编程知识，今天我们就通过案例分析来简单了解一下，微服务架构拆分原则与稳定性保障分析。

南宁达内IT培训微服务架构拆分原则与稳定性保障分析

1、拆分原则

微服务拆分前，需要确定拆分的基本原则，微服务拆分的一个非常重要原则是无状态，无状态服务方便扩展和运维，所以无状态设计需要贯穿到微服务架构设计的全局层面进行思考。

服务拆分粒度并不是越细越好，需要结合当前团队的人员情况而定，比如当前团队只有5个人，如果拆分后的微服务个数超过50，和人员的数量严重不匹配，不仅不会带来效率的提升，反而会导致效率的下降，建议拆分后每个人维护的微服务不要超过3个，并且每个微服务都有相应的备用负责人，规避可能的突发风险;针对多团队异地开发的情况，拆分后每个子团队负责的微服务相对独立，尽量减少异地团队的直接沟通成本。

微服务拆分时经常会遇到一些问题，比如是否需要拆分、拆分粒度的问题等，一般原则是遇到痛点问题时才进行拆分，非拆分不可时才启动微服务拆分，不要为了拆分而拆分。对于拆分方案拿捏不准的场景，尽量先不进行拆分，等想清楚了再定，避免拆分不合理，带来大量返工。

拆分后的微服务组织上层次不要过深，一个请求的处理过程中经过的微服务个数不要超过5个，链路太深会导致定位和追查问题特别麻烦，同时也会带来一定的性能损耗。对于拆分后的子服务来说，尽量避免相互依赖的场景，子服务调用时相互依赖会导致升级和维护时特别麻烦，增加很多不必要的运维成本。

2、微服务稳定性保障的目标

微服务稳定性保障需要从事前、事中和事后全方位进行考虑。微服务架构下，应用程序、依赖服务、网络、硬件等都有可能出现故障，稳定性设计和保障的具体目标如下。

故障预防，尽可能减少故障的产生，绝大多数稳定性问题和稳定性故障发生都有一定的诱因，并且一般是在多种拦截手段均失灵的情况下故障才会发生，如果我们在故障发生前制定完备的稳定性保障措施，可以大限度地减少稳定性故障的发生。

故障快速定位，完全不出故障的业务是不存在的，关键是出故障时能够快速发现故障，只有及时发现，才能在短时间内采取相应的解决措施。

故障快速止损，发生故障后一时间要进行业务止损，恢复业务的正常运行，故障深层次的具体原因可以事后再分析和复盘解决。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。

< 上一篇：南宁达内Java培训微服务架构通信技术应用类型分析

下一篇：南宁达内UI设计培训UI设计思维常用模型都有哪些 >