图解微服务应用的设计原则

前言

什么样的应用才算是一个微服务应用?怎么设计一个微服务架构的应用呢?今天我们就一起来看看微服务应用的那些设计原则。

设计原则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、后话

假如有一天微服务的外部世界十分强壮了,那么我们便可从微服务内部世界来考量服务划分的粒度,比如考虑微服务持续部署的效率等问题。

图注:爱折腾的稻草

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180623G1H0Z400?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券