微服务系统架构

最新推荐文章于 2023-05-29 15:30:27 发布

Java架构狮

最新推荐文章于 2023-05-29 15:30:27 发布

阅读量423

点赞数

文章标签：微服务系统架构 microservices

本文链接：https://blog.csdn.net/m0_69860228/article/details/124897926

版权

回忆一下微服务架构是如何进化产生的，最早出现的是单体应用架构，后来为了具备一定的扩展和可靠性，就有了垂直拆分架构，也就是加了个负载均衡，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构的核心思想是：分而治之，就是开发多个围绕业务领域的组件来构建应用，让组件可以独立的开发、测试、部署和加速。

其优点在于：

从技术角度看：服务注册、统一配置、安全认证、统一日志/告警、分布式事务、持续集成等基础服务要前置于业务模块之前完成，该部分工作如果在业务实现后，重构增加该部分功能会增加不必要的成本。

从团队角度看：架构和团队的影响是双向的，微服务在组织的落地需要实践或者点，需要组织内部成员在：服务划分、持续交付、问题分析等领域形成一些经验后，再分步骤推广。

首先，需要定义一下状态，如果数据需要被多个服务或特定服务的多个阶段共享，可以将其成为状态。

无状态原则并不是说在微服务架构中不允许状态的存在，而是要把有状态的服务改变成无状态的独立业务服务，比如：将状态数据在请求间传递或放到分布式存储中，都可以解决状态服务的问题，这样服务就可以按需动态伸缩。

简单的说，就是前后端代码物理分离，而不是将：JS, HTML, CSS, JSP都堆到一起，后期难以维护。

相同点：

不同点：

根据马丁·福勒介绍，在系统复杂度较小时，单体应用的生产率更高，微服务架构反而降低了生产率。但是，当复杂度到了一定规模，无论采用单体应用还是微服务架构，都会降低系统的生产率。区别是：单体应用生产率开始急剧下降，而微服务架构则能缓解生产率下降的程度。如下图：

在软件开发的世界，没有银弹，架构的选择是基于研发团队、业务需求和市场机会等因素综合考虑的结果，不要人云亦云，也不要因循守旧，

关注