A, AKF split principle
The industry has a simple design concept for a scalable system architecture: the capacity and availability can solve the problem by adding machine.
The concept of cloud computing concept crazy popular today, has been widely recognized system for a rapidly growing size, capacity and performance issues of course bear the brunt. But with the forward growth of the size of the system, in addition to face the problem of performance and capacity, but also brought about growth in the face of system functions and the number of modules time to bring the complexity of the issues and changes in the business of providing differentiated question of the service.
However, many system architecture designed to take full account of these problems, leading to system reconfiguration become the norm, affecting service delivery capabilities, but also a waste of human and financial resources. This "scalable Art," a book proposed a system scalable model --AKF scalable cubic (Scalability Cube).
1, Y axis (Function) functional division of interest applications, based on different service splitter
Y axis expansion will be large, monolithic applications into multiple services, each implement a set of related functions, such as order management, customer management. In engineering common scenario is service oriented architecture (SOA), such as for an e-commerce platform, we can be split into different services, similar to the composition of the following schema:
、
But can be found on a map, when the increase in the number of services, service invocation relationship is complicated, to add a new feature to the system, the number of services to be invoked becomes uncontrollable, which led to confusion on service management, it is generally the case next, we need a mechanism for service registration, forming a service gateway to the service of governance
2, X-axis (horizontal scaling) concerns horizontal scaling, or "accelerator solve the problem."
X-axis and extend our previous simple idea is the same, by the absolute equality of service and copy data to address capacity and availability issues, in fact, is to run multiple instances of micro-services, plus do load balancing cluster mode.
In order to enhance the availability and capacity of a single service, each service is divided X-axis extended.
3, Z-axis (data partitioning) Follow prioritizing services and data, such geographical division
Generally refers to the Z-axis expansion based on the unique needs of the requester, or user, the system is divided, and divided such that a subsystem out isolated but intact. Production of automobile factories to Example: Ford Motor Company in order to develop business in China, or take advantage of China's cheap labor, the establishment of a complete sub-factories in China, and the United States as factories, responsible for complete car production. This is a Z-axis expansion.
工程领域常见的Z轴扩展有以下两种方案
1，单元化架构
在分布式服务设计领域，一个单元Cell就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y轴扩展的SOA架构。客户端对服务端节点的选择一般是随机的，但是，如果在此上加Z轴扩展，那服务节点的选择将不再是随机的，而是每个单元自成一体。
2，数据分区
为了性能数据安全上的考虑，我们将一个完整的数据集按一定维度划分出不同的子集。一个分区（Shard），就是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是同一个分区，数据分区一般包括以下几种数据划分形式：
数据类型：如业务类型
数据范围：如时间段、用户ID
数据热度：如用户活跃度、商品热度
按读写分：如商品描述、商品库存
二、前后端分离原则
何为前后端分离？前后端本来不就是分离的吗？这要从jsp开始讲起。分工精细化从来都是蛋糕做大的原则，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才能使效率越来越高，维护也会变得简单。jsp的模板技术融合了html和java代码，使得传统MVC开发中的前后端如胶似漆，前端做好页面，后端转成模板，发现问题再找前端，前端又看不懂java代码，前后端分离的目的就是打破这尴尬的局面，我们需要的是一个全能的团队，而不是一个个全能的人。
前后端分离原则，简单的将就是前端和后端的代码分离，我们推荐的模式是最好采用物理分离的方式部署，进一步促使更彻底的分离。如果继续使用服务端模板技术，如jsp，把java、js、css、html都堆到一个页面里，稍微复杂一点的页面就无法维护了。
这种前后端分离有几个好处：
1，前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验会更好。
2，分离模式下，前后端交互界面更清晰，就剩下接口模型，后端接口简介明了，更易于维护。
3，前端多渠道继承场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端，例如：微信h5前端、PC前端、安卓前端、IOS前端。
三、无状态服务
对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个状态的服务被称为有状态的服务，反之成为无状态服务。
这个无状态服务原则并不是说在微服务架构里不允许存在状态，表达的真实意思就是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们从前在本地内存中建立的数据缓存、Session缓存，到现在微服务架构中就应该把数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
四、RestFul通讯风格
这里介绍一个“无状态通讯原则”-Restful通讯风格，它有许多优点：
1，无状态协议HTTP，具备先天优势，扩展能力强，例如安全加密有成熟的https。
2，JSON报文序列化，轻量简单，人与机均可读，学习成本低，搜索引擎友好。
3，语言无关，各大热门语言都提供成熟的Restful API框架，相对一些其他RPC框架生态更加完善。
