分布式架构的学习大纲(二)——分布式

RPC

分布式面临的第一个问题无疑是远程调用问题。
曾经在一个线程里的service跑到了远程的另一个服务上去了。
再也不能直接加个@Autoware就直接用起来了。
解决远程调用目前陆续出现了一系列技术。
目前来说，国内做火的使用最广泛的是Dubbo和SpringCloud。
当然两者其实都有很多模块，RPC只是他们其中一个功能而已。
目前SpringCloud已成为趋势。
很多公司的新项目都开始使用SpringCloud，但Dubbo依然占有很高的份额。

分布式锁

不在一个进程里如何来对某个操作加锁。
核心思路是在一个公共的服务上来模拟本地加锁。
主流的技术有使用Redis和ZooKeeper解决。
目前关于Redis集群的锁功能的正确性还存在有争议。
使用ZK的临时有序节点，是经过大企业验证的可靠方案。
当然如果你公司没有人来维护ZK集群，那么做个简单的Redis锁，也是可用的。

分布式事务

流行的说法有7种方案。其中有的很不靠谱。但至少这两种是经过检验的。
当你的系统是涉及资金，要求绝对不能有任何问题，使用TCC，代价是复杂，当然也有相应的框架可用。
其他的一些系统使用可靠消息即可。
关于分布式事务的建议是，能不用就不用，因为成本极高极高，部分情况甚至可以通过打日志手动恢复。
毕竟一年也就那么几条数据需要手动恢复。

一致性问题--CAP问题的C--我认为AP可归在高可用内容中，关于CAP也有一大堆文章，这里就不讲了，只是个知识分类问题，怎么分都可以。

集群内部的一致性问题--通常这个框架已经帮你处理好了。
当某个服务由一个集群组成，比如ZK或者Redis。
一份数据可能存在几群的多个节点上，那么插入一条数据的时候怎么才算插入成功呢？
是所有节点都确认插入了才算成功吗，还是部分成功就可以，怎么确保节点间相互知道彼此插入了数据呢。
这一系列问题其实就是一个集群如何对某个数据达成一致的问题。
这个问题最初是一个叫“拜占庭将军问题”引出，工程化的过程中根据实际情况。
简化成了paxos协议，具体的实现也有不同，比如ZK自己的的原子广播协议，和RAFT。
服务间的一致性问题--需要自己根据实际情况处理。
最典型的就是对于重要的数据的数据库缓存双写一致。
典型的方案是
1.先改数据库再删缓存--为什么是删不是改，百度cache aside pattern。
2.先删缓存再改数据库，删完缓存到改完数据库建的读请求和改数据库请求放入队里做“异步串行化”。

异步调用

服务多了调用关系复杂了起来，如果服务间还是直接调用。
那么服务间的调用关系将变成一张理不清的蜘蛛网。沟通成本极高。
通常会使用mq来做发布订阅式的异步调用。
mq主流的用activeMq，rabbitMq，rocketMq，kafka
activeMq基本不用了，更新巨慢。
rabbitMq很适合小公司，虽然能承受的并发压力不如后两者，但是功能健全，而且有很好用的UI界面。
rocketMq适合有能力定制的大公司使用。
kafka不定制那就它了没问题，好用稳定。
一定注意这种情况使用MQ，是带来了异步，我们用MQ是想解耦，异步是他的副作用而已。
一旦异步，事务什么的又更麻烦了。

服务治理

由一台机器变成了几十上百台服务器。
整个调用链路的可视化，服务器运行状况，访问压力等数据的的实时监控。
为运维带来了新的挑战。
几乎可以成为单独的一个专题，目前，只有大公司有能力定制自己的服务治理框架。