为什么会产生微服务架构，原来是这些原因( 二 ) _微服务架构

垂直拆分将各业务子系统解耦出来，但是每次请求在不同阶段遇到的瓶颈与负载是不一样的，因此我们对可以使用水平拆分的思路对服务进行拆分：

文章插图

水平拆分
首先用户请求通过http协议到达网关，网关将json数据格式转为protobuf，通过tcp长链接与服务层、数据层通信获取目标数据然后返回给用户。这样拆分加长了用户请求链路时延，但是如果服务全部部署在同一内网，而且使用protobuf格式通信那么这个时延在几十毫秒内是完全可以接受的。业务层与数据层完全解耦便可以轻松将不同类型的服务进入冗余部署，同时在不动业务层的同时修改它的数据存储方式。
如果我们对系统即做垂直拆分也做水分拆分，那么就有了微服务的样子,

文章插图

水平拆分
每级服务只能调用比他低级别的服务，如果搜索服务层只能掉账户接口层服务而不能调账户服务层接口，这样可以用来避免服务A调用服务B，而服务B同时又调用了服务A的循环调用问题。但是这样的拆分粒度仍然不够的，比如搜索系统和推荐系统都要调用账户系统的一些基础查询、修改逻辑，那么需要在搜索与推荐的服务层两次实现同样的代码吗，这样显然是不合理了，任何不能复用的设计显然都是有问题的。如果通过编写SDK库提供Jar包的模式去实现这个功能呢？，显然也存在问题比如推荐系统是Python实现，而搜索系统是JAVA实现的呢？所以这里我们将每个子系统可共用代码部分也单独抽取出来作为一个服务。