微服务架构理论-扩展立方体篇

　　近几年的的微服务概念大火特火，随之框架也变得大火起来，尤其是spring boot，可能是因为spring cloud火起来的原因 搞得沉寂多年的dubbo也开始更新变得火起来。

说起微服务对于不了解整个系统架构历史的小伙伴可能有些迷惑，怎么就突然一下子就微服务了，有点摸不着头脑，到底咋回事那？听我娓娓道来！

　　很久很久以前的程序员都很牛逼一不开心就自己写个操作系统自己玩，玩着玩着最后就剩下了几个，比如我们熟知的windows，linux，苹果OS，这是我们使用最底层的

操作系统，在操作系统上面我们还要运行我们的应用软件，这个运行的应用软件就是我们今天重点讲解的，然而这个软件一般指企业级软件。

　　企业级软件最初只想把那些纸质的数据进行电子化，但是不断的发展，不断的发展，不过也就几十年的时间就出现了如下的架构（原谅我上面墨迹了那么多没用的）：

　　

　　通过上面的发展我们我不在一一讨论除微服务之外的各种优缺点，直奔主题，为什么要用微服务？？

　　用三个字回答就是“可扩展”，围绕可扩展我们最终实现了微服务化，以及实现了对应的实例框架 spring boot 等

　　也就是说，如果 “可扩展” 是抽象类的话，那么微服务就是继承了可扩展并实例化了（原谅我的程序思维）！

　　可扩展也是很直白，那就是可以根据实际需要进行扩展。最后很多牛叉的人和组织总结了一个AKF可扩展的立方体

　　

　　X,Y,Z轴分别代表了不同的扩展方向，下面简单解释一下：

　　　　X轴代表无差别的克隆服务和数据库。用一个人来说X轴的例子可能是公司很多相同的事情分给多个人来干，简单快捷

　　在每个克隆实体间无差别的分配任务，每个克隆实体都可以完成其他克隆实体的任务，无论任务分配给了谁。

　　每个克隆实体都有工具和资源来尽快完成所分配的任务。

　　　　Y轴代表的是按照交易处理的数据类型，交易任务类型或两者组合分割的工作责任。我们一般用动词或资源进行分离，比如：

　　登录，查询，结算等等。把同样的工作分割成流水线式的工作流或并行的处理流，Y轴代表的更多是对工作的“工业革命”，将耦合紧密的

　　工作进行进行专门处理。Y轴实质代表责任、行动或数据。实施成本一般比X轴扩展代价高。假如有100个人造100辆车，每个人负责

　　造一辆，完成造车全部的任务，不如让100个人执行子任务，如发送机的安装、喷漆、四轮定位。这样就会减少前后交互所需要的上下文

　　信息，更专注做某件事情。

　　　　Z轴通常基于请求或客户的信息进行分割。比如我们在分客户时会有 “普通会员”和“vip会员“之分，服务“普通会员”与服务“vip会员”可能

　　会有不同。vip会员可能会特殊对待，会有单独的人在处理vip会员的事情。但是他们都是会员。再比如一些客户可能需要专门的账单、

　　付款条件和基于业务量的特别互动。我们可能安排最好的财务代表、甚至特别的经理负责一个或多个客户，以专门处理他们的独特需求。

　　这样将减少执行绝大多数的计费功能所需的知识量，从而服务好广大客户。

　　Z轴分割是成本最高的分割方向，Z轴分割有助于提高交易和数据的可扩展性，如果实施得当也有助于扩展指令集和过程

　　

好下面列举一下按三个轴划分的例子

　　X轴一般就是负载均衡，比如用F5等硬件设备进行端口轮训负载。

　　Y轴主要体现在我们按业务拆分服务，比如登录服务，订单服务等

　　Z轴主要是对一些有特殊要求的业务执行单独流程处理，比如按地区提供对应地区客户的服务，根据不同地区不同客户群的生活习惯等进行差异化服务。 

　　下面的图会直观一点

　　

 　　AKF扩展立方体XYZ三个轴可以根据实际情况酌情使用其中一个两个或三个都是用，并且三个轴既可以无限向下扩展也可以无限向上扩展。

我们在设计系统架构的时候可以将AKF扩展立方体作为理论指导，设计完之后回过头来看看是否可以做相应的扩展。