关于服务化,以及软件系统的服务化,是一个大的概念。我通过一些以服务化为主题的文章输出,总结下来服务化是一种思想,是一种软件过程,并没有严格的非此及彼的标准化定义,但是有一定的量化指标可以参考。
话又说回来,软件开发是一项工程行为,按照软件开发的定义,是有一套理论基础作为支撑的,在大学教育里有专门的软件工程专业。
本文试图在软件开发理论与中小型软件项目的最佳实践的基础之上,探寻最大程度的软件系统服务化。
服务化系统首先应该是分布式的系统。
分布式系统
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统有以下几个特征:
1 副本
副本(Replica)是分布式系统最常见的概念之一,指分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中,为了对外提供高可用的服务,我们往往会对数据和服务进行副本处理。有副本的概念,就会关联到副本数据一致性问题。
2 故障总会发生
不要担心故障,故障在分布式系统中总会发生,我们要做的是预防故障,处理故障。
分布式系统的核心就是处理各种各样的异常情况。
服务交互的三种状态
服务交互的三种状态,可以理解为网络请求的三种状态,“成功”、“失败”、“超时”,
尤其注意失败和超时是不一样的,失败代表着明确的处理结果,而超时是一种不确定的状态。
这三种状态的区分对于跨系统之间定义通讯协议时很重要。
超时与重试
分布式系统需要区别对待 RPC 的“成功”、“失败”、“超时”三种状态。当出现“超时”时,可以通过发起读取数据的操作以验证 RPC 是否成功(例如银行系统的做法)。
或者设计分布式协议时将执行步骤设计为可重试的,即具有所谓的“幂等性”。
失败的操作在一定场景下可以重试至成功。
【有些执行步骤是可重试的,而有些是不能重试的。幂等性的重点是其任意多次执行所产生的影响均与一次执行的影响相同,在事务型设计中 保持幂等性是尤为重要的】
本文对幂等性不做过多介绍。
C/S与P2P
这里回顾下,网络通讯中两种通讯模式 C/S模式和P2P模式,C/S模式强调的是客户端发起和服务器端之间的角色定位,P2P模式认为没有严格的客户端和服务端。
P2P模式下,在一组服务化的系统中,每一个节点都是调用链中的一环,除了用户最前端和数据持久化的最末端,几乎每一个节点都在向上游获取服务,向下游提供服务。
显然分布式系统中,使用的通讯模式都是P2P模式。
基于以上内容的理解,本文对服务化做一个简单的定义
定义服务化
服务化是软件服务的一个过程,是不断更迭和完善的。有如下几个可量化的属性
共享性
1 服务化的系统最终功能交付物被多个下游系统依赖调用,调用方>=2。也就是一个服务是可以被多个服务消费方共享使用的。服务需要独立部署,不需要与其他项目深度耦合。
有功能边界
2 服务化的系统具有一定的抽象功能,抓大放小,解决系统核心功能及主要矛盾。
我们需要定义系统的核心模块及数量,也就是服务化的粒度
稳定性
3 服务化的系统要稳定,可靠,可控
健壮性
4 服务化的系统具有一定的健壮性,弹性。对于异常可以进行平行过度,拥有降级等容错机制。
弹性思维
弹性是服务化系统的一个特点,要求系统在遇到异常和外部破外时,能够保持原有最小化的功能输出,不至于被压倒。设计者在设计服务系统时,需要建立弹性思维。
容错降级
总结
本文从分布式的特点,服务交互状态,以及网络通讯模型几部分着手,基于理论,实践,可复制性,复盘开发经验和理解的原则,对软件服务化进行了4个纬度的定义。之后我会梳理一些开发案例进行分解。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。