认识达内从这里开始

认真做教育专心促就业

合肥达内培训微服务架构开发都需要注意哪些问题

发布：合肥达内软件培训
来源：互联网
时间：2022-04-24 09:28

微服务架构开发是目前大多数软件开发程序员在开发软件的时候都会用到的一个架构技术，而本文我们就通过案例分析来了解一下，微服务架构开发都需要注意哪些问题。

合肥达内培训微服务架构开发都需要注意哪些问题

微服务解耦后，会将一些业务程序从原来数据库查询的方式，转变成远程对象调用，这个过程我在原来的回答中提过，这是反人性的。形成复杂度和需要约定的接口都带来了比SQL查询更大的工作量。而且更反人性的方式就是数据库也跟着微服务进行分库，到底哪些数据需要冗余，哪些数据还能保持数据库范式，基本都能把高程们烦死。

经验欠缺的微服务架构师，容易将微服务切得太细，假如一个单体若被切分成一千个微服务，而且微服务之间用到了远程对象序列化和反序列化，那么这就成了死穴!因为一旦一个微服务的实体对象进行了调整，那么有多少个关联的微服务被污染了，就要不断定位其他微服务的依赖关系并重新发布，这种工作量已经超出了本该解决业务问题的工作量。

因此微服务的划分一定要注意，而且RPC之间的对象传递尽量用简单、松散的结构来做。微服务划分的程度根据业务不同而粒度不同，有种约定是一个微服务进行大的重构，需要一周的时间，做为微服务粒度标准。

微服务架构的考虑，不应该是对未来的考虑，而是对过去单体式应用出现问题后的一种架构重构，从第一节中的图可以看到其重构过程，在互联网医疗的例子中微服务的重构进一步趋向于消息驱动、事件驱动。

从以往实施微服务的经验教训中，我总结出来的经验，如果是新项目的架构师，可以先选择单体应用，然后根据业务发展一点点迭代重构到微服务上来，即便过程中微服务的架构不那么纯粹，甚至单体应用和微服务很长一段时间共存，也要慎重从新的项目上直接去设计微服务。

因为谁也不是算命先生，能估算到自己业务系统会在哪一天，哪个层面，哪个范围就一定需要微服务化解耦。只有系统运行快到那个阶段了，才能让架构师更容易做到合理的微服务化决策。当然了，也有人会有疑惑，系统设计成单体，谁还有心思继续重构微服务，不如直接做成微服务架构多省事，而我想说的是，若无重构之力行，切勿有微服务之念想。

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

< 上一篇：合肥UI设计培训搜索功能的应用都有哪些注意事项

下一篇：合肥达内培训分布式数据存储应用都有哪些注意事项 >