前言
什么样的应用才算是一个微服务应用?怎么设计一个微服务架构的应用呢?今天我们就一起来看看微服务应用的那些设计原则。
设计原则1、AKF拆分原则
图注:AKF拆分原则
AKF扩展立方体,是一个AKF公司的技术专家抽象总结的应用扩展的三个维度,理论上按照这三个扩展模式,可以将一个单体系统进行无限扩展。
X轴:水平复制,即单个服务运行多个实例,做个集群加负载均衡的模式;
Z轴:类数据分区,即按用户的地域进行数据分区,北京、上海、深圳等多建几个集群;
Y轴:服务拆分模式。
2、前后端分离原则
图注:前后端分离
前后端分离,不仅要做到技术代码的分离,还要做到物理分离的部署方式,不要使用之前的服务端模板技术,如JSP。
分离模式下,前后端交互界面更清晰,就剩下接口和模型,后端的接口简洁明了,更容易维护。
前端多渠道应用场景更容易实现,后端无需变更,采用统一的数据和模型,即可支撑PC前端、移动APP等访问。
3、无状态服务
图注:无状态服务
状态:如果一个数据需要被多个服务共享,则这个数据就是状态。
有状态服务: 依赖于状态数据的服务称为有状态服务。
无状态服务: 不依赖状态数据的服务成为无状态服务。
这里提到的无状态服务原则,并不是说在微服务中不允许存在状态,而是将有状态的业务服务改为无状态的计算服务,把“状态”数据迁移到对应的“有状态服务”中。
eg:本地内存中建立的数据缓存、Session缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。
迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。
4、无状态通信原则(RESTful通信风格)
图注:无状态通信
无状态通信:每次通信都是独立的,不存在共用的数据(状态),不相互依赖某一数据。
无状态通信的最佳实践就是RESTful通信风格,RESTful具有如下优势:
天生适合无状态的HTTP协议,具有很强的扩展能力;
JSON报文序列化,轻量简单,人机均可读,学习成本低,对搜索引擎友好;
RESTful具有语言无关性,各大热门语言都有成熟的API框架。
如何进行服务划分
依托微服务四大设计原则,我们来看看如何设计微服务应用的服务粒度(服务划分)。
1、微服务的内外部世界
按照服务边界上下文(Bounded Context),我们可以将微服务应用的世界划分为外部世界和内部世界。
微服务的外部世界:
微服务外部的客户端、界面、系统、设备;
微服务之间的外部数据交换;
微服务之间的外部远程调用;
微服务的内部世界:
微服务内部需要实现的业务功能(场景);
微服务内部所需的资源(类库、数据库、服务器、网络IP、操作系统等)
2、指导思想
就目前软件应用的现状来看,微服务的外部世界是十分脆弱和不可预期的,比如说网络:网络的中断、网络的安全、网络的延迟等都是脆弱和不可预期的。因此我们在设计微服务的服务划分时,需谨记微服务的“外部世界”远比“内部世界”重要这样一个指导思想。
遵循这一指导思想,我们应该从微服务“外部世界”来界定微服务的粒度,主要从以下几个方向去思考:
1、先从微服务的外部客户端分析和识别微服务的主要目的、需要处理和运算的业务场景(功能)是什么,从而得出微服务的Pre-Bounded Context.
2、根据Pre-Bounded Context,便可近一步分析,微服务之间的外部数据交换是否会增加开发的技术难度,是否会影响整体应用的架构可靠性,是否会存在分布式事务(数据一致性问题),是否会产生其他负面影响。
3、在第二步的基础上,再近一步分析,是否因为微服务之间的外部远程调用过多,导致大量的网络延迟,从而影响整体应用架构的性能。
3、后话
假如有一天微服务的外部世界十分强壮了,那么我们便可从微服务内部世界来考量服务划分的粒度,比如考虑微服务持续部署的效率等问题。
图注:爱折腾的稻草
领取专属 10元无门槛券
私享最新 技术干货