共享服务中心对内和对外的协作共享
共享服务平台(Shared Platform as Service, SPAS)
服务化建设野蛮发展带来的问题
- 服务的数量和业务覆盖范围越来越大
- 基础中间件:分布式数据库、分布式缓存、分布式配置、分布式文件系统、分布式日志、分布式远程调用框架
- 电商领域:商品、库存、交易、支付、搜索、商品类目、商品结构话数据
- 其他:比较小众的图像识别、图像搜索…
- 应用和业务架构越分越细,服务越来越专业化,跨领域理解的成本越来越高
- 服务安全控制层缺乏
- 广义的安全:数据机密性、服务的可用性、SLA的遵循
- 从广义安全的角度:
- 防止恶意调用行为;
- 杜绝由于人为或系统的错误发生错误调用行为;
- 要能管理服务的依赖使用关系,提供满足SLA规范协议的服务;
- 无安全措施导致的问题
- 应用不知道哪些下游业务在使用我的服务,服务升级、变更需于依赖业务方沟通要花大量的时间;
- 服务被未授权的业务方调用;
- 随意发布服务。
- 开发体验很不友好,产品在接入流程,开发使用手册建设非常之差
- 整体服务体系缺乏一个统一的服务治理层
- 缺乏对这种分布式服务层面各种服务能力的抽象模型;
- 缺乏从整体角度把各种分布式服务能力管理起来的产品;
共享服务平台的目标
SPAS目标:对集团的服务更好地进行治理和共享,服务能力的在线化、数据化的过程。
从SPAS直接找到满足需要的服务;通过流程规范接入,强化服务之间的依赖和安全管理;服务提供者与消费者之间的直接信息交互通道。
-
应用服务Online、组装新服务 ==> 快速发现服务、简单实用服务
-
服务规范、服务安全机制 ==> 服务接入
-
服务管理控制台、服务状态报告 ==> 服务动态信息
共享服务平台的建设思路
服务:服务端暴露出来的一种服务接口,与服务消费者相对应,代表服务端的一个具体能力。在SOA架构中服务被当成一个组件对象,组件就包括服务接口和附加在这个接口上的组件规范:服务策略、限制、描述等,称为组件化服务。
服务化:服务化是一个动词,更像一个商业策略,核心是从产品能力转化直接服务客户的能力。
产品能力 是从产品出发,以产品为核心,就像我们从产品出发抽象API;
服务化 是以面向客户的服务为核心,就像我们根据用户的需求来提供最适配用户需求的设计方案,是按需服务(Service On Demamd)的体验。服务化的思路是把产品和服务的中心转移到用户身上,以方便用户使用、降低使用成本为目标。如果服务的用户是开发,我们就需要从开发的需求出发;如果服务的用户是运营,就要从运营的需求出发。
实现共享服务的条件
- 找到一个合适的服务化对象; API
- 建设对象服务化的基础设施;
- 服务化实施阶段;
- 增强服务和基础设施极限服务的精细治理;
SPAS构建步骤
1. 确定服务化的对象是API
2. 建立共享服务的基础设施,实现API的服务封装
根据对淘宝业务需求分析,共享服务基础设施包括:
- 服务的描述元数据
- 服务的注册于发现机制
- 服务的访问控制与安全策略
- 应用服务Portal
- 服务依赖与运维管理
- 服务SLA协议
- 服务消费者的管理于支持工具
- 服务辅助工具支持
- 服服务成本核算于服务能力变现
- 文档于开放工具支持
3. 服务化实施阶段
把阿里巴巴电商体系内原生API服务变成共享服务平台上的组件化服务,是一个渐进的过程,需要也无妨的参与。把服务化实施划分为API as Service、Product as Service、 Solution as Service 三个阶段。
1)API as Service
API称为服务是最基本的要求,API有通过API元数据的自描述,API自描述元数据能够与服务治理工具交互,那么服务就具备了一下几个特点:
- 服务还是通过原来的接口暴露,API元数据对API没有侵入性。
- 服务具有共享服务平台上的所有服务治理的能力。
- 所有服务都具有相同的使用体验,降低横向学习成本。
2)Product as Service
把API形态的服务利用共享服务平台“封装服务”来暴露让开发者尖叫的服务。
- 初始的API设计会顾及产品的设计、业务兼容性、平滑发展等各个因素,所以API会显得很复杂。
- 用户可以在共享服务平台上利用API服务来开发和部署组合服务。
- 服务组装旨在真正实现服务粒度的敏捷,让服务开发和部署的流程可以非常简单和快速,服务提供者利用服务平台的服务辅助开发工具实现在服务端或者客户端封装的服务。
经过这一阶段,服务提供者提供的服务就不仅是一堆API的列表,还会包括从业务需求出发梳理出来的一些场景化的服务接口。而且利用共享服务平台提供的服务组装机制,完成服务简单的组装,从而快速提供特定业务需求的短期服务。
3)Solution as Service
业务的扩展是基于服务的扩展,而不是基于代码的方式进行扩展,这是 Solution as Service 的目标。
共享服务平台与业务方协作
参与者
| 参与角色 | 对应的应用列表 | 协作方式 |
|---|---|---|
| 共享服务平台 | SPAS | 建设服务Portal 等基础设施 建设应用服务的应用账号系统,建立起应用、服务、服务提供者和消费者的概念 实现服务治理的基本能力 协助服务市场参与方一起制定服务市场的规范并用产品方式实现 帮助业务接入到服务化平台 |
| 服务提供者 | 商品、交易、UMP、店铺、物流、库存、推荐、淘宝、天猫、聚划算等 | 与SPAS一起制定服务化的基础规范并落地 把应用服务接入到服务化平台,利用SPAS的基础工具把服务接口化、规范化,方便消费者的接入 利用服务化工具建设自己的应用领域的特色的、个性的、高质量的服务市场 利用SPAS的服务治理工具管理自己的服务:安全控制、运维管理、服务质量报告、成本核算、对消费者支持 提供场景化的解决方案的服务 |
| HSF、MetaQ、Notify、Diamod、ConfigServer、TDDL、EagleEye、搜索等基础分布式中间件 | 作为分布式服务的基础通道接入服务化SDK以实现对上层服务化的支持 共建服务治理控制台 |
|
| 服务消费者 | 商品、交易、UMP、店铺、物流、库存、推荐、淘宝、天猫、聚划算等(消费者通常也是提供这种服务) | 使用SPAS发现需要的服务,并接入 使用SPAS的辅助开发工具提高服务接入的效率 利用SPAS的SLA支持工具与服务提供方达成服务的细粒度协议支持 获取服务的质量报告和调用分析 获取服务提供方的在线支持 |
业务中台与前端应用协作
1.业务中台对前端核心业务的紧密沟通机制
2.建立分歧升级机制
3.岗位轮转推动真正的换位思考
4.业务持续沉淀及共建模式
业务中台的绩效考核
- 服务稳定是重中之中
- 业务创新推动业务发展
- 服务接入量是衡量服务价值的重要考核
- 客户满意度触动服务的提升