知道这些坑，你还敢乱把单体架构拆成分布式吗？( 二 ) 一、背景我们在聊架构风格之

文章图片
3、单体架构的案例：库存系统
最初的库存代码分层如下：API：对外提供的dubbo服务common：封装了公共方法dao：封装了数据库dbcp交互domain：实体类innerApi：系统内部api交互router：废弃rpc：上下游rpc交互service：业务逻辑层web：web服务层worker：任务调度层

文章图片
在最初很长的一段时间里，我们部署了两个单体服务，一个是API接口来保障上游的库存查询以及调用，另一个是web服务的后台管理平台。这两个单体服务很好的贴合了最初的业务迭代和发版速度，但是后来随着业务的增加附加调用量的增加，单体服务的无论是从性能和稳定性都出现了较大的波动。
4、意料之外，情理之中的事故惨案
2015年6月26日晚，也是一个促销活动的前夕，库存的web管理平台挂了，原因就是大量库存导入，服务器的内存不足导致机器宕机。商家、运营无法通过导表的方式去维护库存数量，在这之前已经经历过了多次横向扩容。还是出现了预料之外的流量和稳定性的问题。

文章图片
而且在接下来的大促过程当中，库存的单体服务API接口也承受了非常大的压力。
一方面是上游调用方有很多，比如APP端首页中的门店网关，查询商品是否有库存，是否展示。购物车加车，也会查询商品库存的数量，提单则会对库存数量进行扣减，乃至后续的订单取消同样也会调用库存接口。
另一方面大的KA商家通过中台对接对库存进行操作，为了尽可能的让商家门店的库存和线上平台的库存保持一致，减少线上线下库存不一致导致的超卖、少卖。中台同步间隔时间都非常短， 5分钟-10分钟就要全量同步一次。后续随着入驻的商家增多，这个量级增长得也非常的迅速。于是我们开启了单体服务向分布式服务演进的大门。
三、分布式架构
1、分布式架构的优缺点
1）分布式架构的优点可用性高可扩展性高系统容错性高业务代码可读性高维护简单
这些优点正是我们当时库存系统欠缺的，尤其是其中的可用性、系统容错性，是我们系统演进迭代的首要目标。
《分布式架构体系》中描述到，分布式架构的核心理念也是按照（功能、业务、领域等）对系统进行拆分，通过合理的拆分结构，实现各业务模块的解耦，同时通过系统级容错设计，在廉价硬件基础设施上构建起高可用、可扩展的开放技术体系。
所以我们库存系统到底要按照什么进行拆分，功能？业务？领域？在拆分之前我们一定要明确设计的目标，避免目标方向错误带来的人力、成本资源的浪费。在弄清楚目标之前，我们先了解下分布式架构的缺点，通过了解这些缺点来衡量满足我们目标的前提下，需要进行哪些方面的取舍，就如CAP原则一样，只能满足其中的两个， AP或者CP 。
2）分布式架构的缺点服务多，人员对拆分后的业务模块理解要花费一些成本技术栈升级耗费人力分布式事务的保持业务模块之间的rpc交互损耗
库存系统的特点，高可用、高并发、强数据一致性。接下来我们就来讲一下，库存是如何从单体架构向分布式架构进行的转型。
2、单体架构如何向分布式架构转型
因为库存面临的最大的问题是稳定性，所以我们首先针对功能进行了拆分。
1）功能拆分