为何在云平台中使用REST作为架构设计风格绪论.pptx

为何在云平台中使用REST作为架构设计风格数字化企业云平台 平台 · 让创新无限 挑战：服务类型繁杂，如何统一抽象？ 知识库 过程管理 项目质量 部署 监控 … … 招聘流程 订单流程 采购流程 支付服务 清算服务 … … 计算能力 存储能力 网络能力 数据库服务 缓存服务 … … 我是谁？我从哪里来，我到哪里去 方案：一切皆为资源！ 计算能力 存储能力 网络能力 数据库服务 缓存服务 … … 我是资源！我从资源来，我到资源去 知识库 过程管理 项目质量 部署 监控 … … 招聘流程 订单流程 采购流程 支付服务 清算服务 … … 优势： 简洁，避免了很多概念，学习成本低，容易传播 解耦，接口定义与具体实现分离 简单，有很多可用的工具 … … 通过”一切皆文件”的概念，形成了 Unix 的生态，Unix的哲学是自下而上的 参照Unix的设计风格：一切皆为文件 一致的架构风格简化了整体架构的复杂度 Unix 的哲学是自下而上的，一致性的底层架构设计降低了上层业务开发的复杂度 盲目试错 万马齐喑 有序创新 资源的描述不仅要一致，还要不同的语言和工具链都能使用 资源提供者 资源消费者 Adapter API SPI API SPI Service Service 标准 标准 标准 标准 标准 我们需要的是Machine-to-machine的系统集成，目标是让服务发布者和消费者在最小约束下自由演化 就像制造业的协作方式 原材料 (资源) 需求 协作 产品 (资源) 服务 反馈 协作 协作 协作 创造 REST风格是软件资源集成最好的数字化描述风格 功能性 功能性 非功能性 功能性 非功能性 基于 HTTP 的最佳实践 REST风格是Machine-to-Machine最佳集成方式 例如从网站优化看 REST 风格： 搜索引擎可以识别的，就是机器容易识别的 搜索引擎 Product U1 Domain U Capability 数字化企业云平台基于资源的微服务集成方式 Service U.SPI Domain Y Capability Y.API Domain Z Capability C.API Boundary B Metadata PA Adapter B Model Boundary C Metadata CA Adapter C Domain X Capability X.API X.SPI Model Boundary A Metadata DS A DS C DS = Data Standard, 数据标准 API = Application Programming Interface, 功能发布接口 SPI = Service Provider Interface， 资源依赖接口 Core = 功能规格，包含Model, Controller, Service, DAS U1.Core.Model := U1.Core.Model + A.Model U1.Core.Model != A.Model 则需要Model适配 Controller Core DAS Y.SPI Z.SPI U1.SPI U1.API Boundary作为边界标准，解耦能力规范 Boundary标准核心是Model符合业务数据标准 Capability能力规范必须以人机两种形式 Adapter作为产品适配器独立于产品规格 Product 是根据Capability进行的一种能力实现 Model U.Model U.API DS A 我们使用REST风格带来的优势 简单 具备丰富的工具集，不用自己操心 可伸缩 更好的性能和缓存支持 松耦合 统一接口 M2M 自解释 一目了然 REST 风格 HTTP 最佳实践 Resteasy Fastjson Swagger-ui Mockito Nginx Etcd 我们使用REST风格遇到的挑战 不理解架构风格的重要，片面从技术实现角度出发 REST 风格难以描述复杂业务 对数字化(M2M)缺少理解，过度陷入REST的格式讨论 缺乏对HTTP工具链的了解，好处体现不明显 技术平台 RC 资源容器 看板 数字化企业云平台的 DevOps 逻辑视图 (前台角色交互场景) Design 设计 Test 测试 Dev 开发 Deliver 交付 Monitor 监控 Offline 下线 Trouble 故障 Efficiency 能效 Plan 规划 (后台服务) 基础设施平台 RDB 数据库 IAM 身份 SPM 产品 SRM 资源 SEM 环境 QAF 质量 VCS 源码 CI 编译 BPR 介仓 DPR 部仓 Portal 门户 FS 文件系统 RPC 同步调用 MQ 异步调用 SER 序列化 C