微服务设计、拆分原则
⼀、AKF拆分原则
  业界对于可扩展系统架构设计有⼀个朴素的理念：通过加机器就可以解决容量和可⽤性问题。
  这⼀理念在云计算概念疯狂流⾏的今天，得到了⼴泛的认可，对于⼀个规模迅速增长的系统⽽⾔，容量和性能问题当然是⾸当其冲的。但随着时间的向前，系统规模的增长，除了⾯对性能与容量的问题外，还要⾯对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务的问题。
  然⽽许多系统在架构设计时为充分考虑这些问题，导致系统重构成为常态，⽽影响业务交付能⼒，还浪费⼈⼒财⼒。对此《可扩展艺术》⼀书提出了⼀个系统可扩展模型--AKF可扩展⽴⽅（Scalability Cube）。
  Y轴扩展会将庞⼤的整体应⽤拆分为多个服务，每个服务实现⼀组相关的功能，如订单管理、客户管理等。在⼯程上常见的⽅案是服务化架构（SOA），⽐如对于⼀个电⼦商务平台，我们可以拆分成不同的服务，组成类似下⾯的架构：
、
  但通过上图可以发现，当服务数量增多时，服务调⽤关系变得复杂，为系统添加⼀个新功能，要调⽤的服务数变得不可控，由此引发了服务管理上的混乱，所以⼀般情况下，需要采⽤服务注册的机制形成服务⽹关来进⾏服务治理
  X轴扩展与我们前⾯朴素理念是⼀致的，通过绝对平等的复制服务与数据，以解决容量与可⽤性的问题，其实就是将微服务运⾏多个实例，做集加负载均衡的模式。
  为了提升单个服务的可⽤性与容量，对每⼀个服务进⾏X轴扩展划分。
  Z轴扩展通常是指基于请求者或⽤户独特的需求，进⾏系统划分，并使得划分出来的⼦系统相互隔离但⼜是完整的。以⽣产汽车的⼯⼚来举例：福特公司为了发展在中国的业务，或者利⽤中国的廉价劳动⼒，在中国建⽴⼀个完整的⼦⼯⼚，与美国⼯⼚⼀样，负责完整的汽车⽣产。这就是⼀种Z 轴扩展。
⼯程领域常见的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框架⽣态更加完善。
微服务在哪里

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。