PaaS平台设计思想

目录

文章目录

PaaS的概念

PaaS架构核心思想

组件思想​

基础业务组件

PaaS组件设计

Workflow组件

PaaS组件开发

组件开发过程

PaaS接口设计

角度决定设计

PaaS核心理念

PaaS重点关注的三方面

当前的思考

技术的未来

 

---

PaaS的概念

• 平台即服务（platform as a service，缩写作PaaS）是一种云计算服务，提供运算平台与解决方案堆栈即服务。在云计算的典型层级中，平台即服务层介于软件即服务与基础设施即服务之间。
• PaaS将软件研发的平台做为一种服务，以软件即服务（SaaS）的模式交付给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快SaaS的发展，尤其是加快SaaS应用的开发速度  —— wikipedia

---

PaaS架构核心思想

• paas设计的前提是组件化。
• paas架构是组件化支撑和驱动的，组件的发展决定了paas的广度，组件的聚合决定了paas的深度，组件间毫无关联却又围绕着paas息息相关，对内固守组件边界随需扩展，对外暴露标准接口隐藏实现。
• 上层的应用层按自身需求调用paas组件并结合业务做逻辑组装，将节省下来的时间精力放在构建更复杂完善的业务逻辑上，重点关注业务创新。

组件思想

 

基础业务组件

 

PaaS组件设计

• 在设计时就确定边界，不能随意延展，定义标准接口，规范入参出参，确定组件核心功能，规范异常处理。
• 组件一定是自描述的，即不用依赖边界外的概念来描述自身，从概念定义上实现解耦，这样在设计和开发时也一定是解耦的，这样的组件在以后的发展进化时就是完全独立的，将全部发展精力聚焦其自身，具备无限可能。

Workflow组件

 

PaaS组件开发

• paas组件内部的开发，可以理解为将组件结构设计成针对应用程序对象领域的DSL，最后再进行整合的过程，从DSL角度出发来评判核心逻辑和接口，其实也是很有意思的。这样编写出来的代码，抽象度高，应对未来修改能力强，才算上是不错的组件。

 

组件开发过程

• 首先是技术评审，通过后启动开发工作。
• 定义接口，分为dubbo和restful两种接口。内部评审通过后，再与业务方进行接口评审，然后进行开发。
• 先定义接口再编写实现的方式，称为面向接口开发，区别于面向对象开发，更符合SOA理念。接口其实声明的是组件的行为，这种先明确行为再开发的方式，也称为行为驱动开发(BDD，Behavior-driven development)，与TDD是不同的概念。

PaaS接口设计

• 接口标准化
• 接口说明
• 接口服务路由
• 接口版本管理
• 接口授权管理

角度决定设计

 

PaaS核心理念

 

PaaS重点关注的三方面

• 基础业务

组织架构和用户组

审批流工作流

权限 ……

• 通用模型

透明分布式缓存模型

分布式存储模型

分布式事务模型 ……

• 效率工具

数据迁移工具

缓存配置工具 ……

 

当前的思考

• 大型甚至是超大型客户需求对paas的挑战
• 私有云单独部署，升级维护是个问题
• 商业解决方案IOE(IBM小型机 Oracle数据库 EMC存储设备)，贵，很贵，非常贵。而且去IOE是国家对政府信息系统提出的要求，企业呢
• 巨量访问压力下，系统架构如何变革
• 性能衡量标准，怎么模拟、测试、验证
• 随需扩展，怎么扩展，扩展的是什么

• 统一的数据库分库访问路由，能否跨库分页查询
• 透明的缓存使用方式，缓存数据自动更新
• 分布式事务(思考方向：ACIDCAPBASE)
• 多租户环境下数据的绝对访问安全
• 数据权限模型，多业务适配，服务，工具
• 事件驱动模型，如何帮助业务点之间解耦
• 数据迁移工具，能否做到异构数据库间迁移，能否做到不停服务在线迁移

• PaaS组件的价值，到底还是在于使用，使用的前提在于了解，如何了解这么多的组件
• 组件的管理，版本、兼容性、优势、不足
• 如何收集组件使用上的问题和反馈，改进的方向怎么确定，由业务决定，还是由自身决定
• 业务方使用组件的痛点在哪，如何使用，以痛治痛是最糟糕的方式
• 业务自发主动的愿意使用，一方面要宣讲推广，核心还是在于我们能提供什么样的价值

• 组件服务管理
• 服务发现
• 访问安全
• 智能路由
• 决策竞选
• 断路器
• 全局锁
• 集群状态

技术的未来

• 摩尔定律
• 从价格看未来
• 从性能看未来
• 从容量看未来
• 从带宽看未来
• 技术的未来，创造、改变世界的乐趣

---

 

​​​​​​​

---