SOA与微服务

最新推荐文章于 2023-04-26 13:44:16 发布

JAVA高级架构v

最新推荐文章于 2023-04-26 13:44:16 发布

阅读量325

点赞数

文章标签： java 架构

本文链接：https://blog.csdn.net/t4i2b10X4c22nF6A/article/details/81124904

版权

微服务并非它的体积足够小，而是它的责任足够单一，很多人误解了「微」的真实含义，认为服务拆分得足够小就是微服务了，其实并非这样。此外，「微」还有“微不足道”的意思，也就是说，某个服务出现故障，它不会影响整个系统。
微服务并非细粒度服务的组合，也就是说，粒度要细到什么程度，这取决于对业务功能的把控能力。此外，微服务是一种架构思想，包括看得见的微服务，还包括看不见的基础设施和自动化技术作为支撑。
目前市面上常用的微服务架构dubbo+zk，spring cloud
微服务的核心：注册中心（Service Registry）、服务提供方（service provider）、服务消费方（service consumer）。不过现在为了方便，又提出了网关的（service gateway）的概念，配动自动完成服务的注册和发现。
从什么角度能区分出或者划分微服务和 RPC 分布式之间的区别或者关系？

微服务是一种应用架构模式，而 RPC 是一种远程调用方式，它们是不一样的概念；而在微服务中会出现服务之间的调用，为了确保性能，我们一般采用 RPC 来调用。

我认为微服务架构用于业务较复杂或目前业务简单但将来有可能变得复杂的架构，建议视具体情况来确定合理的架构，不要为了微服务而去微服务。

微服务是SOA的一种轻量级的解决方案，其本质还是SOA，只是更容易落地而以。

对于满足以下条件可以考虑使用微服务：

1. 应用变得越来越大
2. 项目存在多种开发语言
3. 经典架构模式太重
4. 修改一个bug需要平滑升级
5. 需要对系统细粒度监控
6. 提升系统可用性，如果一个系统挂了，不会对整个业务产生致命影响

在微服务架构中，建议尽量避免服务之间的调用，因此服务粒度的切分是至关重要的；服务间的调用会产生分布式事务问题，建议采用“最终一致性”方法来确保分布式事务，业界有两种常用做法：CQRS 和 Event Sourcing。

事务补偿机制说简单点就是，在应用程序中通过代码的方式做到数据的还原。一般情况下，我们需借助消息队列与日志追踪等方式来实现。

1、微服务的事务控制本质上是分布式事务控制，建议使用“最终一致性”来确保。
2、在容错方面，需要有基础设施平台的支撑，比如服务网关的熔断机制

1. 微服务业务拆分可按整体业务组件来拆分，也可按单一业务功能来切分。建议切分步骤从粗到细，逐步细化，否则开始就过细，导致依赖性太高，增加复杂度。
2. 拆分服务时需降低彼此之间的耦合性，尽可能一个服务只做一件事情，即“单一职责原则”。

微服务的粒度控制取决于我们对业务的理解与把控能力，一切所谓的原则都是不靠谱的。

微服务需要考虑服务多版本问题，尤其是服务升级时，需要做到平滑，对整体系统没有任何影响。

对CSDNJava架构技术，对架构技术感兴趣的同学，欢迎加QQ群859729143，一起学习，相互讨论。

群内已经有小伙伴将知识体系整理好（源码，笔记，PPT，学习视频），欢迎?加群免费领取

分享给喜欢Java，喜欢编程，有梦想成为架构师的程序员们，希望能够帮助到你们。

关注