首先,这篇文章我会用自己的话来给你讲微服务之道,避免一些很专业的名词,纯粹个人理解
要了解微服务,就要了解微服务的前世今生
讲个故事吧,在混沌初开的时候,天上有100个众神,每个神都有民众向他们请求,他们来满足民众的需求,然而有一天有个神因为太优秀而忙碌病倒了,导致民众向他的请求无效了,而别的神只能看着,都有各自的任务,却帮不了他.
这个神已经深深感觉到了,民众的请求才是最重要的,但是不能因为自己病倒了,就帮助不了民众的基本需求,于是他召开紧急会议,来来来,我们100个人在健康的情况下确实可以满足民众需求,但是呢非常时期不行,那怎么办呢,简单,加神不就行了,于是神创造了神,又加了200个神进来,这样三个神负责同一个任务,还成立任务网管机制(反向代理),根据规则把任务发给3个神中的一个,这样大家又开始忙碌起来了,也没出什么叉子,但是有一天民间人口暴增,需求五花八门,众神的业务已经不能满足民众了(应用颗粒度大),这时候需求每个神把自己负责的模块拆解,比如按照民众需求拆解,这个神以前负责中国的,任务太大了,这时候只让他负责华东,或者山东,或者山东下面的威海.....等等,根据神的数量以及能力进行拆解(多微合适).
于是神又召开会议,改改改,改成什么样子呢,分家,按照任务细粒度分家,三个神一组,有独立的任务代理,有独立的任务记录,形成了每个组都是独立的服务组,如果山东的民众突然需求变了,不会影响到江西的神的业务,于是微服务诞生了.
相比较以前,微服务解决了众多问题,比如单点故障,以及冗余耦合等,那微服务也有问题,凡事都有问题吗,谁能完美无缺呢,微服务第一就是耗钱,这个也是缺点哦,对于初创公司钱就是命脉,所以要不要微服务,多微合适,都是要具体考量的,另外一个缺点就是,应用多了后,每个独立的子系统交互方式也就变了,分布式一致性问题就出来了.
突然有一天,江西的民众山东的民众,上海的民众开会碰头了,一问感觉对方的任务很适合自己,民众任务合体,这是单祖神的业务已经满足不了民众的需求,怎么办,再改,改的方式还有很多:
第一,又加了一组神,分别请求三组神,然后按照三组神返回的任务结果,自己拼拼凑凑,组合新的任务结果,然后给民众
第二.如果按照上面的方式做了,然后还把拼凑的结果给记录到本地了,这就换了一个模式,而且很常用.
第三:民众发来请求,一组神请求二组神,二组神,请求三组神,三组神请求四组神,返回结果,就就是羊肉串一样,一个调用一个
所以哪一种方式都可以实现民众的需求,但是有最好的选择,也有最坏的选择,要分场景,要分时间
然后还有一天,山东的民众做起买卖了,要给山西的人转钱.
这时候众神开始炸锅了,难受.怎么保证山东人的钱要么成功转到山西人的口袋里,要么都失败呢(分布式事务一致性CAP),因为应用是独立的,这时候有个聪明的神,提出了两阶段提交,就是我们加个协调的神,协调的神开始问一组神,准备好了没,一组神评估自己的状态,嗯准备好了,然后协调神问二组神准备好了没?二组神看看自己的状态,还没?OK,不提交操作,回滚,保证事务一致性,假如二组神说OK了,那么协调神通知一组神,说二组准备好了,你提交吧,然后一组调教成功,这时候协调神去跟二组说,一组提交成功了,你也提交吧,然后二组说我提交成功了,OK完成任务,下班休息.
这样好,保证事务一致,但是太重了,而且一旦协调者玩游戏去了,不管协调了(宕机),那就出现阻塞了,难受
这时候神又召开会议,我们能不能再准备阶段前加个询问,可以啊,协调者先问问一组好了没,一组嗝屁了,没回答,OK,结束.增加了询问阶段有什么好处呢,可以提前校验和查找超时的应用,更容易保重一致性,而且不会一直锁定资源,那么重,这个叫做三阶段提交协议.
总之分布式微服务是个好东西,用好了叫做好东西,用坏了,我们习惯把它叫做坑
