对Dubbo分布式微服务架构初步理解（欢迎指正错误）

我们为什么要用dubbo框架
       相信很多看到我这篇文章的小伙伴都已经对dubbo等类似的微服务架构有了一定的了解，知道dubbo是为了应对高并发、大流量场景的。那高并发场景和普通场景的不同之处，就是我们用dubbo的原因，下面我用一个例子来解释下。

单体架构（ORM）：
       假设你是个秃头程序猿，现在点了一家叫长发飘飘小店的外卖（一次web请求），需要经过洗菜切菜（数据库）、做菜（后台）、配送（前台）到你手上，而且需要等你下班后收到外卖才算完成一次点外卖。这样几个人点还好，如果人多了根本忙不过来。然而你发现吃了这家外卖头发居然长出来了，于是这家店的订单成倍增长，根本应付不过来。这时候集群架构就出现了。

集群架构（MVC）：
       集群架构分为好多种，有主从架构，双主，一主多从等。这里打个不恰当的比方，这些架构本质上为了提高服务器读的性能，洗菜（写）比切菜（读）工作量小，所有切菜（读）多分配人手（服务器）。如上图，集群架构可以看出长发飘飘外卖店生意太好了，开了好几家连锁店（复制几份系统），并且对洗菜切菜（读写服务器配置）进行调整，更好满足订单需求。然鹅，程序员吃完后不仅头发长出来了，还都有了女朋友，于是外卖店的订单又成几何倍数增长。

分布式架构（RPC）：
       现在的长发飘飘外卖店每一个流程就是一家店（一个系统），炒菜需要炒菜店，豆浆需要豆浆店。假设一分套餐包括炸鸡排、现磨豆浆、米饭、辣椒炒肉（4个生产者），还有一个外卖打包店（一个消费者），还有一个传菜中心（注册中心），以及监督小组（监控器）。每次下单需要外卖打包店对把你点的饭拆分成不同的部分，然后由传菜中心委派给炒菜店、豆浆店制作。这样可以根据口味喜好安排人做菜，比如鸡排订单很大，就增加好多鸡排店。同时相对于单体架构，也不会因为一个员工检查出携带传染性病毒关闭整个外卖店（服务宕机）。分布式架构店是独立的，所有只需要关闭一家店，不影响整个外卖流程。