SOA与中间件

Posted 2020-10-02 bili111

在分布式系统中，有一个基础的理论 CAP，Consistency一致性 Availability可用性 Partition Tolerance分区容忍性，任何一个系统都不可能同时满足这三个条件（高富帅或白富美很难同时满足），结构化存储（关系型数据库 RDBMS）满足的是CA，半结构化存储(MongoDB HBase)满足的是CP。但是可以看出，它们都需要满足一致性的要求。

在分布式系统中，组件部署在多台机器上，它们通过网络相互协同工作，共同完成系统的使命。在分布式系统中，将各个功能单元当成服务来对待，这就是SOA，面向服务的架构。很明显，Openstack采用的就是SOA架构，因为它提供了很多的服务，供消费者（虚拟机）去使用，例如Neutron网络服务，Nova计算服务，Cinder块存储服务等。在分布式系统中，分布式事务是非常重要的，如果要完成一个操作，可能需要远程调用好几个服务，每个服务中都有独属于它的事务，如何保证这些事务链要么执行成功，要么有某个事务执行失败就全体回滚呢？一种众所周知的方式就是两段式提交，系统中有一个协调者，负责协调所有的参与者（服务）。在第一阶段，协调者喊预备，此时所有参与者都会去执行相应的事务，并将Undo和Redo信息记入事务日志中，但是都不提交，而是给协调者返回一个消息，反馈是否都准备好了;在第二个阶段，协调者会判断，如果都准备好了，那么就给所有参与者发出指令，使它们全部提交。相反，如果某个服务因为操作失败，给协调者返回未就绪的消息，那么所有的事务都会回滚。两段式提交其实也是有缺点的，在协调者发出预备消息后，如果某个参与者没有接受到消息，那么协调者就会一直等待（阻塞）。所以后面又引入了三段式提交，三段式提交比较晦涩难懂，在实际用的时候结合实际情况再好好研究下。

SOA中有一个服务注册中心（基于ZooKeeper实现），所有的服务都会在这里进行注册，表明自己提供了哪些服务，访问的Endpoint是什么。当一个请求到来时，会先负载均衡，分流到某个具体的服务器，服务器在调用后端服务的时候，会先去服务注册中心获取数据，缓存到本地并查找服务地址，最后才是真正的远程服务调用（RPC SOA的具体实现方式）。

 

 

在分布式系统中，大量使用了中间件技术，几乎每个服务的内部都采用消息中间件，使得各个业务组件解耦，异步调用大大提高了系统的性能。

 

分布式锁

在双十一抢货的时候，如果前端点击太快，导致后端重复调用了接口。两次调用一个接口，这样就会产生同一个请求执行了两次，而从用户的角度出发，他是因为太卡而点了两次，他的目标是执行一次请求。

对于高并发场景，我们往往需要引入分布式缓存，来加快整个系统的响应速度。但是缓存是有失效机制的，如果某一时刻缓存失效，而此时有大量的请求过来，那么所有的请求会瞬间直接打到DB上，那么这么大的并发量，DB可能是扛不住的。那么这里需要引入一个保护机制。当发生“缓存击穿”的时候加锁，从而保护DB不被拖垮。

解决方案：基于数据库实现分布式锁，或者用缓存来实现分布式锁（推荐使用）。因为缓存比较轻量，并且响应快、吞吐高，最重要的是还有自动失效的机制来保证锁一定能释放，缓存的分布式锁主要通过Redis实现。