精华内容
下载资源
问答
  • paas平台架构
    千次阅读
    2017-08-14 23:20:16

    【分享说明】:

    我会花很多时间或浅或深的研读一本书,然后总结一些提炼出来的精华,用简短的语言,让其他人能够用很少的时间大致知道这本书能带给自己的价值,如果适用自己,鼓励买一本正本实体书细读和收藏。

    通篇会以原文目录为结构,给出提炼内容,如果不重要或者一看目录就懂的,会保留目录,有不明白的,以原文学习为参照。

    所有分享内容,为了区分,会以》开头,可能有多行缩进,或差异化颜色表示。


    【书名】:《分布式服务框架原理与实践》李林锋(华为PaaS平台架构师)著

    【发行】:2016年

    【适用】:分布式0基础人员,希望强化实践的,复杂服务平台构建者,微服务方向,java更宜,不适用于用c++做定制化创造框架组件方向的(我个人在这个方向上,后文简单过了一下),更偏基于各种已有组件,构建大型功能集成平台。

    【总结】:

    1、书不是很长,章节非常多。前面从宏观上讲了需求目标和大体架构,后文分章节细分和实践讲解。

    2、整体架构形态讲解的很细致到位,了解全面。

    3、后面太长,有重复和冗余,连续读心累,最好后面章节边实践练习边研讨。

    4、读完之后视野有开拓的感觉,值得回味再读一遍。

    【章节总结】

    1章应用框架演变讲了从MVC、RPC、SOA到微服务框架的演变原因、特性和设计原则,深刻体会一下需求场景,有了框架的宏观认识。

    2章分布式服务框架入门通过几个常用的框架的分析,整体的讲了分布式设计的原理和组成组件。

    3-9章围绕各主要组件,详细的讲了设计考虑因素和一些具体实践。

    10-19章围绕分布式架构的一些特殊场景,详细的讲了设计考虑因素和一些具体实践。

    20章细节的讲了微服务框架。

    21章总结了分布式设计实践中遇到的一些其他方面的总结。


    【正式分享】

    1章应用架构演进1
    1.1
    传统垂直应用架构2

    LAMPMVC为典型
    1.1.1
    垂直应用架构介绍2

    》简单说就是单线,上是访问入口,最底层是数据存储

    》高负责时,通过上层分流(F5七层负载均衡或SLB)做分流,后面是对等逻辑部署(每个分流完全一致)
    1.1.2
    垂直应用架构面临的挑战4

    1复杂应用维护成本高,效率低:一次编译出错全部重新打包

    2团队效率差,公共功能重复开发

    3系统可靠性变差,雪崩效应,一个模块故障,其他模块压力暴增

    4维护和定制困难,代码量增加导致

    5新功能上线周期变长:测试周期长,功能无法独立上线

    》进化:一些公共功能抽以出来,提供api访问,跨进程形成rpc调用
    1.2RPC
    架构6

    》远程调用框架
    1.2.1RPC
    框架原理6

    4个核心技术点

    1、远程服务需要以某种形式提供服务调用相关信息

    2、远程代理对象:将本地调用封闭成远程服务调用

    3、通信

    4、数据序列化
    1.2.2
    最简单的RPC框架实现8
    1.2.3
    业界主流RPC框架14

    》介绍4

          1FaceBook开发的ApacheThrift:高效完备,丰富的选择

          2Hadoop子项目Avro-RPC:良好的定制化支持,传输和业务分离

          3caucho提供基于binary-RPCHessian:轻量简单易用

          4google gRPC:高性能通用
    1.2.4RPC
    框架面临的挑战17

    》负载均衡实现路由,随着服务增加,单点压力过大

    》需要额外增加一个服务注册中心,客户端通过大量缓存路由来降压

    》随着业务增多,服务关系复杂,启动顺序难以理清

    》服用调用增大,质量问题突显

    》服务上线容易下线难

    》进化:单纯的RPC治理能力都不健全,需要通过服务框架+服务治理解决
    1.3SOA
    服务化架构18

    》粗粒度松耦合的以服务为中心的框架
    1.3.1
    面向服务设计的原则18

    1、服务可复用

    2、服务共享一个标准契约

    3、服务是松耦合的,尽可能不依赖其他

    4、服务是底层逻辑的抽象

    5、服务是可组合可编排的:多个服务组合成一个新服务

    6、服务是自治的,逻辑由服务控制,不依赖其他服务

    7、服务是无状态的

    8、服务是可被自动发现

    1.3.2服务治理19

    》至少7条挑战

    1、分布式框架下的服务调用性能

    2、服务化框架如何支持线性扩展

    3、如何实现高效、实时监控

    4、大规模分布式下的故障快速定界和定位

    5、分布下式海量日志检索、模糊查询

    6、服务的流控(业务流、事务)、超时控制、服务升降机(增删设备)

    7、服务的划分原则,如何实现最大程度复用

    8、更多……

    SOA的治理

    1、服务定义:对服务进行标识,与使用团队协调确保满足需求,避免重复工作

    2、服务生命周期治理:计划(未实现)、测试(不服务或有限服务)、运行(服务阶段)、弃用(标识弃用,只减不加)、废弃(下线,从注删中心移除或标记移除)

    3、服务版本治理

    4、服务注册中心

    5、服务监控

    6、运行期质量保证:限流、迁入和迁出、升降机、权重调节、服务超时控制

    7、快速故障定界定位手段:1、日志汇总索引2、事件跟踪

    8、服务安全:主要指服务权限
    1.4
    微服务架构21

    》通过将功能分散到离散的各个服务中以实现对解决方案的解耦
    1.4.1
    什么是微服务21

    》主要特征

    1、原子服务,专注于一件事

    2、高密度部署

    3、敏捷交付

    4、微自治
    1.4.2
    微服务架构对比SOA22

    》两者差异

    1、拆分粒度不同:SOA粗,重点是异构服务化

    2、服务依赖:微服务解耦,尽可能不依赖

    3、服务规模不同:SOA打包为主,微服务部署规模膨胀

    4、服务治理:SOA静态治理,微服务动态治理

    5、微服务敏捷交付为主,小团队研发
    1.5
    总结23
    2章分布式服务框架入门25

    》服务化改造的核心技术就是:分布式服务框架
    2.1
    分布式服务框架诞生背景26
    2.1.1
    应用从集中式走向分布式26?

    》尽可能拆分

          纵向拆分:按属性不同分类处理

    横向拆分:按本质不同分块处理,拆分公共等
    2.1.2
    亟需服务治理28
    2.2
    业界分布式服务框架介绍29
    2.2.1
    阿里Dubbo30

    》主要质量属性

    1、连通性:组件间长连接和缓存

    2、健壮性:很多组件挂掉不影响服务

    3、伸缩性:服务中心对等集群、服务提供者无状态

    4、扩展性:插件设计+管道设计
    2.2.2
    淘宝HSF33

    》框架总结

    1、配置化开发,对业务代码低侵入

    2、插件管理系统

    3、异步NIO(一种通信框架名称)通信,多种序列化方式

    4、灵活的路由能力

    5、多协议地

    6、多种服务治理策略
    2.2.3
    亚马逊CoralService35

    》特点总结

    1、支持多协议

    2、轻量级框架,非常容易与已有系统集成

    3、配置化开发

    4、与亚马逊的其他基础设施集成,实现DevOps
    2.3
    分布式服务框架设计36
    2.3.1
    架构原理36

    》通常抽象成3

    1RPC层:本质是通信层,通信和序列化

    2FilterChain层:本质是控制和框架层,负载均衡、统计、通知、重试等

    3service层:业务对接层

    》功能上看核心:服务治理中心和服务注册中心
    2.3.2
    功能特性37

    》服务订阅和发布

    配置化发布和引用服务

    服务自动发现机制

    服务在线注册和去注册

    》服务路由

    默认提供随机路由、轮循、权重路由等

    粘滞链接:总向同一个提供方发请求,记忆功能

    路由定制

    》集群容错

    Failover:失败重试其他节点,读操作或幂等性写操作

    Failback:失败自动恢复,重试等,通常用于消息机制

    Failfash:只发起一次调用,失败立即报错

    》服务调用:同步、异步、并行

    》多协议:私有协议、公有协议

    》序列化:二进制、文本

    》配置中心:本地静态和配置中心动态
    2.3.3
    性能特性39

    》高性能、低时延、性能线性增长(不随着服务增大、负载增大而明显增长)
    2.3.4
    可靠性39

    》服务注册中心

    服务健康状态检测

    故障切换

    HA:高可用,全部挂掉不影响已存在服务

    》清除单点状态

    服务无状态:任意一台宕掉不影响服务

    服务集群容错:只要集群还有1台就正常

    》链接健壮性

    心跳检测

    断连重连
    2.3.5
    服务治理40

    》服务运行状管控

    服务路由:高峰修改路由导流

    服务限流

    服务迁入迁出:高峰迁出

    服务降级:强制减用资源

    服务超时控制:保持成功率

    》服务监控

    性能统计

    统计报表

    告警

    》服务生命周期管理

    上线审批

    下线通知

    服务灰度发布

    》故障快速定界定位

    分布式日志采集

    海量日志在线检索

    调用链可视化展示

    运行日志故障定位

    》服务安全

    敏感服务的授权策略

    链路安全:针对调用者,客户端
    2.4
    总结41
    3章通信框架42
    3.1
    关键技术点分析43
    3.1.1
    长连接还是短连接43

    》通常是长连接,节约资源
    3.1.2BIO
    还是NIO43

    BIO:同步阻塞模式 NIO:支持多路复用非阻塞
    3.1.3
    自研还是选择开源NIO框架46

    BIO有不足,开源经历实践,netty
    3.2
    功能设计47
    3.2.1
    服务端设计48

    》重要设计原则

    1、只提供上层api,不绑定具体协议

    2、提供的api屏蔽底层通信细节

    3、服务端功能不要求全,而是扩展性
    3.2.2
    客户端设计50
    3.3
    可靠性设计53
    3.3.1
    链路有效性检测54

    ping-pong:发心跳,立即回,请求-回应型

    ping-ping:对等心跳,双向心跳
    3.3.2
    断连重连机制56
    3.3.3
    消息缓存重发57
    3.3.4
    资源优雅释放58
    3.4
    性能设计59
    3.4.1
    性能差的三宗罪59

    》罪一:网络传输方式问题,同步通信压力增大,通信变差

    》罪二:序列化性能差

    》罪三:线程模型问题导致开了大量线程
    3.4.2
    通信性能三原则60

    》同步的3
    3.4.3
    高性能之道61
    3.5
    最佳实践61
    3.6
    总结64
    4章序列化与反序列化65

    》跳过
    4.1
    几个关键概念澄清66
    4.1.1
    序列化与通信框架的关系66
    4.1.2
    序列化与通信协议的关系66
    4.1.3
    是否需要支持多种序列化方式67
    4.2
    功能设计67
    4.2.1
    功能丰富度67
    4.2.2
    跨语言支持68
    4.2.3
    兼容性69
    4.2.4
    性能70
    4.3
    扩展性设计71
    4.3.1
    内置的序列化/反序列化功能类71
    4.3.2
    反序列化扩展72
    4.3.3
    序列化扩展75
    4.4
    最佳实践77
    4.4.1
    接口的前向兼容性规范77
    4.4.2
    高并发下的稳定性78
    4.5
    总结78
    5章协议栈79

    》简单过了一下
    5.1
    关键技术点分析80
    5.1.1
    是否必须支持多协议80
    5.1.2
    公有协议还是私有协议80
    5.1.3
    集成开源还是自研81
    5.2
    功能设计82
    5.2.1
    功能描述82
    5.2.2
    通信模型82
    5.2.3
    协议消息定义84
    5.2.4
    协议栈消息序列化支持的字段类型85
    5.2.5
    协议消息的序列化和反序列化86
    5.2.6
    链路创建89
    5.2.7
    链路关闭90
    5.3
    可靠性设计90
    5.3.1
    客户端连接超时90
    5.3.2
    客户端重连机制91
    5.3.3
    客户端重复握手保护91

    》禁止客户端重复连接以避免客户端异常消耗大量句柄
    5.3.4
    消息缓存重发92
    5.3.5
    心跳机制92
    5.4
    安全性设计92

    IP白名单机制
    5.5
    最佳实践协议的前向兼容性94
    5.6
    总结95
    6章服务路由96

    》简单过一下
    6.1
    透明化路由97
    6.1.1
    基于服务注册中心的订阅发布97
    6.1.2
    消费者缓存服务提供者地址98
    6.2
    负载均衡98
    6.2.1
    随机98
    6.2.2
    轮循99
    6.2.3
    服务调用时延99
    6.2.4
    一致性哈希100
    6.2.5
    粘滞连接101

    》长连接记录状态
    6.3
    本地路由优先策略102
    6.3.1injvm
    模式102

    》优先寻找本jvm,用本地调用替换远程调用
    6.3.2innative
    模式102

    》优先寻找本机jvm,用本机调用替换远程调用
    6.4
    路由规则103
    6.4.1
    条件路由规则103
    6.4.2
    脚本路由规则104
    6.5
    路由策略定制105
    6.6
    配置化路由106
    6.7
    最佳实践——多机房路由107
    6.8
    总结108
    第7章集群容错109
    7.1
    集群容错场景110
    7.1.1
    通信链路故障110
    7.1.2
    服务端超时111
    7.1.3
    服务端调用失败111
    7.2
    容错策略112
    7.2.1
    失败自动切换(Failover112

    》失败重新回到路由入口
    7.2.2
    失败通知(Failback113

    》将失败告诉调用者
    7.2.3
    失败缓存(Failcache113

    》失败保存,等下次:周期性的、可预测恢复的、延时不敏感的、通知类的等
    7.2.4
    快速失败(Failfast114

    》高峰时非核心业务,就调用一次
    7.2.5
    容错策略扩展114
    7.3
    总结115
    8章服务调用116

    》简单看一下
    8.1
    几个误区117
    8.1.1NIO
    就是异步服务117
    8.1.2
    服务调用天生就是同步的118
    8.1.3
    异步服务调用性能更高120
    8.2
    服务调用方式120
    8.2.1
    同步服务调用120
    8.2.2
    异步服务调用121
    8.2.3
    并行服务调用125
    8.2.4
    泛化调用129
    8.3
    最佳实践130
    8.4
    总结131
    第9章服务注册中心132

    》简单看一下
    9.1
    几个概念133
    9.1.1
    服务提供者133
    9.1.2
    服务消费者133
    9.1.3
    服务注册中心133
    9.2
    关键功能特性设计134
    9.2.1
    支持对等集群135
    9.2.2
    提供CRUD接口136
    9.2.3
    安全加固136
    9.2.4
    订阅发布机制137
    9.2.5
    可靠性138
    9.3
    基于ZooKeeper的服务注册中心设计139
    9.3.1
    服务订阅发布流程设计139
    9.3.2
    服务健康状态检测141
    9.3.3
    对等集群防止单点故障142
    9.3.4
    变更通知机制144
    9.4
    总结144
    10章服务发布和引用145
    10.1
    服务发布设计146
    10.1.1
    服务发布的几种方式146
    10.1.2
    本地实现类封装成代理148
    10.1.3
    服务发布成指定协议148
    10.1.4
    服务提供者信息注册149
    10.2
    服务引用设计150
    10.2.1
    本地接口调用转换成远程服务调用150
    10.2.2
    服务地址本地缓存151
    10.2.3
    远程服务调用151
    10.3
    最佳实践152
    10.3.1
    对等设计原则152
    10.3.2
    启动顺序问题153

    》不可控,需要支持乱序
    10.3.3
    同步还是异步发布服务153

    》集群或启动比较快,异步发布是可以的(启动成功,但还有未就绪的)
    10.3.4
    警惕网络风暴154
    10.3.5
    配置扩展154
    10.4
    总结156
    11章服务灰度发布157
    11.1
    服务灰度发布流程设计158
    11.1.1
    灰度环境准备158

    》对灰度环境进行划分、隔离和准备
    11.1.2
    灰度规则设置159
    11.1.3
    灰度规则下发160
    11.1.4
    灰度路由161
    11.1.5
    失败回滚162
    11.1.6
    灰度发布总结163
    11.2
    总结163
    12章参数传递164
    12.1
    内部传参165
    12.1.1
    业务内部参数传递165
    12.1.2
    服务框架内部参数传递168
    12.2
    外部传参169
    12.2.1
    通信协议支持169
    12.2.2
    传参接口定义170
    12.3
    最佳实践171
    12.3.1
    防止参数互相覆盖171

    》没有好办法,系统可以预先定义声明给业务方不要覆盖
    12.3.2
    参数生命周期管理171

    map无限追加,需要控制
    12.4
    总结172
    13章服务多版本173

    》简单看一下,主要思路就是版本号管理
    13.1
    服务多版本管理设计174
    13.1.1
    服务版本号管理174
    13.1.2
    服务提供者175
    13.1.3
    服务消费者175
    13.1.4
    基于版本号的服务路由176
    13.1.5
    服务热升级177
    13.2
    OSGi的对比178
    13.2.1
    模块化开发179
    13.2.2
    插件热部署和热升级184
    13.2.3
    不使用OSGi的其他理由185
    13.3
    总结185
    14章流量控制186

    》简单看一下
    14.1
    静态流控187
    14.1.1
    传统静态流控设计方案187
    14.1.2
    传统方案的缺点188
    14.1.3
    动态配额分配制188
    14.1.4
    动态配额申请制190
    14.2
    动态流控191
    14.2.1
    动态流控因子192
    14.2.2
    分级流控192
    14.3
    并发控制193
    14.3.1
    服务端全局控制193
    14.3.2
    服务消费者流控194
    14.4
    连接控制195
    14.4.1
    服务端连接数流控195
    14.4.2
    服务消费者连接数流控195
    14.5
    并发和连接控制算法195
    14.6
    总结197
    15章服务降级198

    》跳过
    15.1
    屏蔽降级199
    15.1.1
    屏蔽降级的流程199
    15.1.2
    屏蔽降级的设计实现200
    15.2
    容错降级202
    15.2.1
    容错降级的工作原理202
    15.2.2
    运行时容错降级204
    15.3
    业务层降级205
    15.4
    总结205
    16章服务优先级调度207

    》跳过
    16.1
    设置服务优先级208
    16.2
    线程调度器方案209
    16.3Java
    优先级队列210
    16.4
    加权优先级队列211
    16.5
    服务迁入迁出212
    16.6
    总结213
    17章服务治理214

    》跳过
    17.1
    服务治理技术的历史变迁215
    17.1.1SOAGovernance215

    17.1.2分布式服务框架服务治理217
    17.1.3AWS
    云端微服务治理217
    17.2
    应用服务化后面临的挑战218
    17.2.1
    跨团队协作问题219
    17.2.2
    服务的上下线管控220
    17.2.3
    服务安全220
    17.2.4
    服务SLA保障221
    17.2.5
    故障快速定界定位221
    17.3
    服务治理222
    17.3.1
    服务治理架构设计223
    17.3.2
    运行态服务治理功能设计225
    17.3.3
    线下服务治理232
    17.3.4
    安全和权限管理234
    17.4
    总结237
    18章分布式消息跟踪239

    》跳过
    18.1
    业务场景分析240
    18.1.1
    故障的快速定界定位240
    18.1.2
    调用路径分析241
    18.1.3
    调用来源和去向分析242
    18.2
    分布式消息跟踪系统设计242
    18.2.1
    系统架构243
    18.2.2
    埋点日志244
    18.2.3
    采样率247
    18.2.4
    采集和存储埋点日志248
    18.2.5
    计算和展示249
    18.2.6
    调用链扩展251
    18.3
    总结251
    19章可靠性设计253

    》简单看一下,主要策略就是隔离分散风险
    19.1
    服务状态检测254
    19.1.1
    基于服务注册中心状态检测254
    19.1.2
    链路有效性状态检测机制255
    19.2
    服务健康度检测256
    19.3
    服务故障隔离257
    19.3.1
    进程级故障隔离257
    19.3.2VM
    级故障隔离259
    19.3.3
    物理机故障隔离260
    19.3.4
    机房故障隔离261
    19.4
    其他可靠性特性262
    19.4.1
    服务注册中心262
    19.4.2
    监控中心262
    19.4.3
    服务提供者262
    19.5
    总结263
    20章微服务架构264

    》简单看一下
    20.1
    微服务架构产生的历史背景265
    20.1.1
    研发成本挑战265
    20.1.2
    运维成本高267
    20.1.3
    新需求上线周期长268
    20.2
    微服务架构带来的改变268
    20.2.1
    应用解耦268
    20.2.2
    分而治之270
    20.2.3
    敏捷交付271
    20.3
    微服务架构解析271
    20.3.1
    微服务划分原则272
    20.3.2
    开发微服务272
    20.3.3
    基于Docker容器部署微服务274
    20.3.4
    治理和运维微服务277
    20.3.5
    特点总结278
    20.4
    总结279
    21章服务化最佳实践280
    21.1
    性能和时延问题281
    21.1.1RPC
    框架高性能设计281
    21.1.2
    业务最佳实践285
    21.2
    事务一致性问题286
    21.2.1
    分布式事务设计方案287

    》尽力避免,因为性能取决于最慢的

    》分阶段处理:先通用准备、都准备好了通用处理、失败通知回滚
    21.2.2
    分布式事务优化288

    》选择一个中间人
    21.3
    研发团队协作问题289
    21.3.1
    共用服务注册中心290
    21.3.2
    直连提供者290
    21.3.3
    多团队进度协同291
    21.3.4
    服务降级和Mock测试291
    21.3.5
    协同调试问题292
    21.3.6
    接口前向兼容性292
    21.4
    总结292


    更多相关内容
  • NFV PaaS平台架构设计

    2021-01-19 18:07:33
    NFV正从软硬件解耦的初级阶段向全面云化、云原生的目标...介绍了NFV PaaS的基本概念和应用场景,分析了NFV PaaS的几种部署选项,在此基础上提出了NFV PaaS平台架构设计方案,为电信运营商构建NFV PaaS平台提供借鉴。
  • 基于k8s+docker的PaaS平台架构.pptx
  • PaaS平台的技术架构进行解析,首次纰漏中服SaaS超市
  • 私有云PaaS平台架构设计.pptx
  • 基于OAM应用模型的大规模可扩展PaaS平台架构实践技术创新变革未来背景OAM应用模型PaaS平台构建实践总结与展望背景-什么是EDAS 控制台/API/CLI Cloud Toolkit 发布Plugin 容器镜像部署 CI/CD发布方式War/Jar 包自动...
  • 基于Devops的PaaS平台架构设计.docx
  • 运营商核心系统的PaaS平台架构.pptx
  • 私有云PaaS平台架构设计PPT学习教案.pptx
  • 基于OAM应用模型的可扩展PaaS平台架构.pdf
  • 私有云paas平台架构设计文库.pptx
  • 2021年云原生大会
  • PaaS 平台架构、现状及未来

    千次阅读 2020-09-11 15:53:09
    做大数据平台的厂商会数自己的大数据平台PaaS,做容器云的厂商会数自己的容器平台PaaS,甚至传统的IaaS厂商会数自己的平台也是PaaS。那么PaaS究竟是什么呢? PaaS的定义 云计算相关概念 我们来说PaaS的定义时...

    说起云计算平台,大家可能都知道有IaaS、PaaS和SaaS。IaaS和SaaS的概念大部分人都能很清晰的认知。说到IaaS大多会讲:存储、计算和网络这三大基础资源,说到SaaS大家会想到各种类型的应用,但是说到PaaS就没有一个非常明确的共识。做大数据平台的厂商会数自己的大数据平台是PaaS,做容器云的厂商会数自己的容器平台是PaaS,甚至传统的IaaS厂商会数自己的平台也是PaaS。那么PaaS究竟是什么呢?

    PaaS的定义

    云计算相关概念

    我们来说PaaS的定义时就要先理解什么是云计算。云计算是指基于互联网等网络,通过虚拟化方式共享IT资源的新型计算模式。其核心思想是通过网络统一管理和调度计算、存储、网络、软件等资源,实现资源整合与配置优化,以服务方式满足不同用户随时获取并扩展、按需使用并付费,最大限度地降低成本等各类需求。

    enter image description here

    目前云计算提供的服务模式主要包含三大类:基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)。

    基础设施即服务(IaaS)

    云计算服务商提供虚拟的硬件资源,如虚拟的主机、存储、网络、安全等资源,用户无需购买服务器、网络设备和存储设备,只需通过网络租赁即可搭建自己的应用系统。IaaS定位于底层,向用户提供可快速部署、按需分配、按需付费的高安全与高可靠的计算能力以及存储能力租用服务,并可为应用提供开放的云基础设施服务接口,用户可以根据业务需求灵活定制租用相应的基础设施资源。在这种服务模式下,用户无需考虑对琐碎的基础设施进行管理与维护,用户可直接在基础设施上面方便地加载应用。IaaS服务对应的用户是系统管理员。

    平台即服务(PaaS)

    PaaS提供商提供应用服务引擎,将软件研发测试和运维的平台作为一种服务提供,如应用程序接口(API)服务或应用运行时服务,用户基于这些服务构建业务应用。从用户角度来说,这意味着他们无需自行搭建开发,测试和运维平台,也不会在不同平台兼容性方面遇到困扰。PaaS服务对应的用户是应用的开发者和运维人员。

    软件即服务(SaaS)

    用户通过标准的 Web 浏览器来使用网络上的软件。从用户角度来说,这意味着前期无需在服务器或软件许可证授权上进行投资;从供应商角度来看,与常规的软件服务模式相比,维护一个应用软件的成本要相对低廉。SaaS供应商通常是按照客户所租用的软件模块来进行收费的,因此用户可以根据需求按需订购软件应用服务,而且SaaS的供应商会负责系统的部署、升级和维护。SaaS提供商对应的用户是应用软件使用的终端用户。

    PaaS

    平台即服务(PaaS)与基础设施即服务(IaaS)是不同的,PaaS并不是IaaS的一个扩展特性,对于基础设施即服务(IaaS)来说,基础单元就是资源,这里的资源是指服务器,磁盘,网络等,IaaS所做的一切就是按照需要提供这些资源。例如,亚马逊(amazon)的EC2服务,所有的工具都以资源为中心,所有的文档都是关于资源的,所有的开发都是专注于资源,同时人们也因为需要这些资源而使用它。

    对于平台即服务(PaaS)来说,基础单元就是应用。那么什么是应用?就是一个系统,就是代码以及所有那些在任何时候都与这些代码通信的服务。这不仅仅是资源,事实上,一个应用是由很多单独的资源绑定在一起组成的。将所有这些资源连接在一起所需要付出的工作量通常被低估了。从一个单一的运行Apache和Mysql的服务器转移到一个拥有单独的负载均衡服务器,缓存服务器,应用服务器,数据库服务器以及冗余的失效恢复的系统架构需要大量的工作,包括前期投入以及后期维护。一个成熟的PaaS平台可以为用户提供上述的所有功能,在减少用户大量工作的前提下,大幅度提升用户应用的开发速度,运行稳定性,可靠性,极大的降低了用户的开发,测试及运维的成本。

    利用PaaS可以做的另外一件事,就是从应用的角度来管理IaaS。通常情况下,使用者对于IaaS的资源需求实质上是来源于运行在IaaS之上的应用,如何根据应用的需求动态的使用IaaS资源又成为摆在云使用者面前的一个难题,PaaS作为SaaS与IaaS的沟通者,可以根据SaaS的需求动态的协调IaaS资源,使IaaS按需分配资源的理念变得更智能,更有实际意义。

    IaaS为云使用者提供了按需分配的能力,用户可以按照自己的需求定制计算资源,存储资源,网络资源,并且利用云端的海量资源随时快速的开启资源,并在工作完成时,随时释放资源,在享受云带来的高可靠性的同时,也最大化的降低了使用成本,提升了资源利用率。

    但是IaaS为云使用者带来的便利只局限在资源这个层面上,云使用者可以快速,稳定,海量的使用资源,但是一旦获取到资源后,云使用者依然要为运行在资源之上的应用搭建各种适配环境(部署),解决应用的各种依赖,安装应用要使用的各种服务,维护应用的运行生命周期。这些问题IaaS都没有解决,或者说,这些问题本质上也不是IaaS需要解决的问题,而是PaaS需要解决的问题。

    综上,IaaS关注与硬件的自动化管理,目标是人与机器的解耦合,提升了效率和性能,而PaaS关注与应用的自动化管理,目标是应用与操作系统的解耦合,提升了弹性和控制。

    PaaS的分类

    通过上面的介绍,大致可以清晰IaaS、PaaS和SaaS的关系以及面向的用户。在继续介绍PaaS的技术细节前,我们需要了解一下PaaS平台自身的分类。Gartner把它们分为两类,一类是应用部署和运行平台APaaS(Application Platform As a Service),另一类是集成平台IPaaS(Integration Platform As a Service)。

    • APaaS是一种面向IT企业和机构的云计算应用开发与部署平台。APaaS主要为应用提供运行环境和数据存储,能够将本地部署的传统应用直接部署到APaaS上。

    • IPaaS是用于集成和协同的PaaS平台,不仅可以支持与现有云服务间的连接性,而且可以以安全的方式提供企业应用的访问能力。IPaaS主要用于集成和构建复合应用。

    大数据厂商的PaaS实际上是属于IPaaS,而容器厂商和IaaS厂商的PaaS大致为APaaS。

    APaaS的一般特性

    大规模分布式系统

    • 完全模块化的分布式系统,保证云平台可靠性;
    • 每个模块单独存在和运行,通过消息总线进行通讯;
    • 系统耦合度低,便于弹性动态扩展;

    弹性伸缩框架

    • 平台自身组件支持实时横向扩展;
    • 根据应用的负载情况,动态加载应用实例;
    • 应用实例支持实时水平扩展;

    运维自动化

    • 日常运维操作简化;
    • 故障自动恢复;

    应用部署简单化

    • 一键式应用快速部署;
    • 支持多种应用开发框架,包括Spring、.NET、Ruby on Rails,Node.js等;
    • 通过buildpack扩展运行不同语言应用的能力;

    支持多种服务

    • 支持多种数据服务,包括MySQL、mongodb、PostgreSQL等;
    • 通过service broker组件扩展多种应用服务能力,包括数据库、中间件、缓存、云存储等。

    主流PaaS平台架构及对比

    了解了PaaS的分类,我们再来看看PaaS的具体技术对比。由于IPaaS具有很强的业务属性,因此这里我们主要来看一下更通用的APaaS,也是目前被大家最多提起的。说到PaaS,相信很多人都会把他和容器、Docker关联起来。下面来看几张图:

    PaaS

    上面这张图可以看出来从容器、编排、部署都自称为PaaS。

    enter image description here

    正如国内的容器厂商都自称为PaaS平台一样,目前大多数人提到PaaS都会想到容器。每过几年总会有新的概念出来。下面再来看一张图。

    enter image description here

    这张图很清晰的划分出了XaaS以及各种概念对应的平台。大家所熟知的容器平台在这里实际上是CaaS的一种。那么CaaS和PaaS有什么区别呢?我们接下来对比一下CaaS和PaaS里面最具代表性的两个平台:CaaS和CloudFoundry。

    Docker/CaaS

    Docker/CaaS 提供直接管理操作基础设施的性能,带来基础设施层面的灵活性。用户 通过直接操作容器可以更灵活的实现应用迁移、部署。但这个更加轻量的平台带来了用户学 习成本和使用复杂度的增加。

    容器云平台的搭建只依托 Swarm/Mesos/K8s 等容器编排调度系统就可以实现,还需 要引入大量的第三方解决方案,例如日志、监控、网络等。这就意味着一定的试错成本,另 外第三方系统的成熟度发展不一,组成一套统一的云平台后进入生产环境的应用需要经过一 定周期的论证和验证。

    Cloud Foundry 平台

    Cloud Foundry 隐藏了基础设施层面的复杂度,提供应用层的管理操作,简化基础设 施和应用的构建管理,平台也使用容器技术,但仅仅是平台架构中的实现细节。通过 CF 可 以更加敏捷的实现应用开发、部署、业务实现等。

    Cloud Foundry 的架构是一个相当完整的 PaaS 架构,模块丰富,平台自身可以提供 对于平台节点、应用的监控、管理,日志,自动化运维等完整的解决方案。每个模块都部署 在一个或多个虚拟机上。这些虚拟机是自动创建的,由 PaaS 管理他的生命周期。它的应用 部署跟 Docker 镜像部署不太一样,它是把程序包直接部署。一个命令行或是一个点击就可 以部署

    在经过长时间的应用,Cloud Foundry 已有很多在生产环境的案例。Cloud Foundry 率先采用 RunC 作为容器运行时,而且刚刚做了一个 25 万个容器集群的测试,验 证了 PaaS+RunC 的大规模集群的支持。

    可以这样来说:容器技术是PaaS平台的底层技术,是PaaS平台不可缺少的部分。但是把容器平台说成PaaS,未免会有点以偏概全了。

    特性CloudfoundryDocker/CaaS
    应用部署方式直接部署程序Release包需要制作Docker镜像
    监控完整解决方案需要集成第三方工具
    日志完整解决方案需要集成第三方工具
    网络完整解决方案需要集成第三方工具
    自动化运维可以和IaaS联动不支持IaaS联动

    PaaS平台和SaaS应用市场的关系

    大家有没有发现一个现象?10年以前,SaaS应用市场是非常少的。现在各大平台都会有自己的SaaS应用市场。出现这种现象的原因无外乎技术的进步,搭建SaaS应用市场的成本降低了。更确切的说:SaaS应用市场是PaaS平台的一种外延。在底层PaaS技术的支撑下,SaaS应用的开发、交付、运营的门槛大幅度的降低了。

    基于PaaS平台构建的SaaS应用市场会逐步加快SaaS应用生态的发展。

    PaaS平台下进行云原生应用开发

    有了PaaS平台帮我们解决底层平台的问题,那么我们的应用开发者要怎么做才能开发出云原生应用呢?12-Factor 为构建如下的云原生应用提供了方法论:

    • 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。

    • 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性。

    • 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源。

    • 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发。

    • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

    这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。

    下面我们一起来看看具体包含哪些要素:

    • 基准代码:一份基准代码,多份部署
    • 依赖:显式声明依赖关系
    • 配置:在环境中存储配置
    • 后端服务:把后端服务当作附加资源
    • 构建,发布,运行:严格分离构建和运行
    • 进程:以一个或多个无状态进程运行应用
    • 端口绑定:通过端口绑定提供服务
    • 并发:通过进程模型进行扩展
    • 易处理:快速启动和优雅终止可最大化健壮性
    • 开发环境与线上环境等价:尽可能的保持开发,预发布,线上环境相同
    • 日志:把日志当作事件流
    • 管理进程:后台管理任务当作一次性进程运行

    PaaS的未来发展

    先抛一个结论:PaaS是云的未来

    IaaS是一个资源转售的生意,PaaS代表了云计算的未来,PaaS解决的是平台架构的问题,同时也是真正做到按需付费。对于业务客户而言,底层技术不会给他们带来直接的业务价值,这也就决定了软件开发商更应该聚焦在业务层。高并发、高可靠、存储服务、应用自身维护等和业务不直接关联的平台服务都可以借助PaaS技术来完成。现在的创业团队可以借助各类PaaS技术快速的创建高并发、高可靠的应用,未来这种模式也会进一步普及。

    • 更融合的调度 物理机、虚拟机和容器各有优势,一个复杂的应用场景会用到各计算平台的优势,融合调度未来必然会成为主流框架。

    • 更融合的编排 说到调度,就离不开编排。当前阶段上云是大趋势,私有云加公有云的模式会长期持续。那么融合的编排框架也必然会成为解决成本问题的一个重要选择。

    • 更细粒度的弹性 IaaS解决了基础设施的弹性,但是还不够。技术的发展会进一步细化弹性的粒度,往更节约的方向发展。

    • 更高的资源利用率 当前的技术及架构下,计算资源很大一部分时间都是闲置的。以有限的资源来应对更高的数据处理要求,资源利用率会随着云技术的发展进一步提高。

    展开全文
  • PaaS云平台架构和运维管理 C 目录 01 分布式PaaS平台介绍 传统企业PaaS设计和业务上云 03 02 PaaS平台功能和构建 基于PAAS平台运维管理 04 第一章:分布式PaaS平台介绍 开发和运维之间的困局 开发团队: 主要工作是...
  • 基于微服务架构和Docker容器技术的PaaS平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源,开发人员只需要开发...
  • 从分析工业界有影响的平台即服务(PaaS)入手,提出了面向互联网应用的PaaS平台的需求,设计了PaaS平台概念模型.基于PaaS平台概念模型提出了面向互联网应用的PaaS平台体系结构,对其中的关键技术做了详细说明.面向互联网...
  • PaaS平台到底是个啥?PaaS平台搭建的思路和未来的趋势是什么?现有PaaS平台案例都有哪些,都是怎么做的?

    虽然 PaaS 提出来了很久,但关于“到底啥是PaaS”这个问题,一万人会有一万零一种解读,似乎PaaS看不见、摸不着,说不清但又绕不开、躲不掉。
    PaaS平台建设指南

    中国企业怎么理解PaaS?

    我们来看几个项目案例。

    案例一、《辽宁广播电视集团(台)广播电视播控系统升级改造项目电视制播云平台智慧应用PaaS层建设项目》

    建设内容包括:

    1、应用层硬件;

    2、应用层软件及授权;

    3、AR和VR制作;

    4、媒资系统应用软件;

    5、演播室文件化备播及播出;

    6、收录系统;

    7、文稿系统及新媒体编辑工具;

    8、公有云和互联网;

    9、智能化运维软件;

    10、融媒体指挥调度大屏软件设计;

    11、环境监控;

    12、中台能力所需软件;

    13、其他,具体详见招标文件……

    案例二、《上海理想2021年PaaS平台软件开发框架项目》

    招标内容:上海理想2021年PaaS平台软件开发框架项目,主要工作内容是统一访问控制、DevOps、日志中心功能、SDK功能、容器管理、监控中心功、新增SQL发布、智能运维、运维工单、Nginx管理等模块功能优化。

    案例三、《中通服创立信息科技有限责任公司物联网平台IoT PaaS平台主数据及相关组件建设技术服务项目》

    提供集团中心与省中心之间的数据同步、稽核等业务,实现集群中心与各省中心的数据共享,设备就近接入等亮点功能;建立位置服务组件、提供基础地图、地址服务、数据服务、设备位置等服务。

    看完这些PaaS平台项目概况,总结起来就是一句话:PaaS是个框,啥都往里装

    关于PaaS的权威说法

    **维基百科:**PaaS是让用户不必要考虑基础设施复度,就能置备、实例化、运行和管理应用程序的一种云服务;同时也能让开发人员创建、开发、打包上述应用。

    **微软云:**PaaS是云里完整的开发和部署环境,交付简单、复杂的各类应用程序。用户按需付费,通过互联网安全访问。

    **InfoWorld:**PaaS是云服务商提供给他们客户,让他们在云上开发、运行、管理应用,而不需要自己构建底层的设施。

    总结起来就是:云时代的应用开发平台 + 应用运行平台

    今天,企业在泛PaaS领域又到底在建设什么?

    关于这个问题,可以用行云的几个案例来阐述。

    案例一:某大型银行信用卡中心

    建设内容:从容器云建设开始,以容器云为底座,建设了持续发布、跨区域编排、中间件监控、国产化等项目。

    收益:形成了教为完备的PaaS体系,有效支持了包括新核心在内200多套业务向微服务演进,一定程度践行了DevOps的快速发版上线,实现灵活的向多地数据中心交付业务的需求。

    案例二:汉口银行

    建设内容:立的项目是“容器云”,做的具体工作是多数据中心 PaaS(容器 + DevOps)。

    收益:原来的想法是先做容器再做DevOps和PaaS,后来经过深入交流采用一体化方式构建。实现了开发、测试、运维整体拉通,DevOps收益明显。另外,采用新的技术实现同城双活数据中心应用交付和业务高可用性。

    案例三:上汽集团

    建设内容:一期PaaS只是建设了容器层,二期PaaS把开发场景引入,实现了开发平台 + 容器运行平台相结合,在三期中重点突出“云原生”能力建设,实现服务网格等新功能。

    收益:仅是容器云的建设并未达到预期的效果,在把开发、测试、运维场景打通后才发挥出PaaS的价值。目前已经大规模推广,并在引入服务网格实现业务可视性的工作。

    案例四:海尔集团

    建设内容:将PaaS能力与海尔卡奥斯工业互联网结合。

    收益:以云服务形式对外开放,让产业链条各类用户可以在云服务上构建和复用机理模型。

    案例五:某市政府智慧城市项目

    建设内容:落地针对智慧城市场景的PaaS方案,除了实现应用开发平台 + 应用运行平台,还建设了PaaS云门户,实现:工作流、审批、资源管理、账单、工单等系统。

    收益:仅是容器云的建设并未达到预期的效果,在把开发、测试、运维场景打通后才发挥出PaaS的价值。目前已经大规模推广,并在引入服务网格实现业务可视性的工作。

    总结起来,企业在PaaS领域的作为不外乎就是为了达到下图目的:
    在这里插入图片描述

    企业的主要需求和本质性的PaaS解决方案有哪些?

    需求一、应用开发更快
    1、结合相应的方法论(如:DevOps);
    2、企业要有数字化积累并形成复用能力;
    3、充分利用云内无限能力;
    4、先进高效的生产力工具(如:容器);

    需求二、用好云

    1. 转变视角:以应用为中心;
    2. 多云策略;
    3. 先进技术(如:容器交付);
    4. 开发和运维打通(DevOps);

    需求三:结合最佳、最新的技术趋势
    毫无疑问,云原生(Cloud Native)技术将会成为并已经逐渐成为核心体系建设的关注点。

    需求四:国产化、符合信创需求

    1. 提早准备,有“选择权”是关键考虑点;
    2. 开放的、可替换组件的架构(如同时支持OpenShift和华为CCE);

    由此,业界也产生了诸多立项名目:
    在这里插入图片描述

    CloudOS 免费在线体验,请点击>

    免费获取《PaaS平台建设指南》,请点击>

    拨开迷雾,万变不离其中的总体设计和演进之路

    PaaS平台搭建思路

    PaaS平台在企业落地的挑战:
    挑战一:企业PaaS平台落地缺少主线,企业独自摸索前行,道路曲曲折折。需要的是对企业IT架构及数字化转型的全盘考虑,制定专业、全面的实施计划,最后分步(并行)实施。

    挑战二:传统、老旧的组织架构造成的建设分裂。最好的解决办法是顶层建设,统一规划;次之是建设过程中(完成后)的对接和协调。

    挑战三:PaaS平台的落地复杂、系统化,需要用到的工具、产品多样化,各类产品组合起来是否合适?技术之间是否兼容?因此需要考虑到的专业技术问题众多,企业极易受到产品选型的技术制约,影响整体规划落地。所以,一个开放可插拔的架构,才能为今天的、明天的各类组件提供“选择权”。

    挑战四:PaaS平台的建设周期不短,各阶段推广受阻影响整体信心。靠谱的外部技术支持团队,帮助共同提升内部团队技术与专业度,打赢PaaS建设的持久战还是在“人”。

    根据挑战,提出解决思路:
    PaaS平台建设新思路


    CloudOS,一站式云原生开发平台,结合容器、微服务、DevOps、中间件等多项云原生技术构建标准研发及PaaS平台。

    CloudOS 免费在线体验,请点击>

    免费获取《PaaS平台建设指南》,请点击>

    展开全文
  • 近几年,随着SaaS层业务的成熟,以及IaaS的环境逐渐扩展和增长,以构建管理平台和服务中台等为雏形的PaaS开始呈现出蓬勃增长的趋势。     作为云基本的形态之一,PaaS是支撑应用和流程不断交织、演进...

     

    据forbes预测,在2020年到来之前,83% 的IT资源都会迁移上云。整个云的生态中,PaaS是最具有抽象属性的云形态,落地较晚也迟迟没有形成统一的标准。近几年,随着 SaaS层业务的成熟,以及IaaS的环境逐渐扩展和增长,以构建管理平台和服务中台等为雏形的PaaS开始呈现出蓬勃增长的趋势。

     

     

    作为云基本的形态之一,PaaS是支撑应用和流程不断交织、演进的平台基础服务,其核心价值在于打通底层大规模共享资源与上层应用的连接,建立资源调度分配的标准和机制,使得IaaS层的资源对用户透明,降低业务和应用部署复杂度,简化业务管理流程和机制,是企业上云不可或缺的关键步骤。PaaS在一定程度上优化企业成本结构,经济效益也是众多市场参与者及用户的关注点。

     

    但由于缺乏标准化、既定做法和持续领导者,当前PaaS市场的建设重点并不在于直接的经济效益,而是着重于构建和形成紧密的产业生态。

     

    根据Gartner报告,截至 2019 年,整个 PaaS 市场有 360 多家厂商,在 21 个品类下提供 550 多种云平台服务。在如此庞大的市场中,并没有作为行业标杆的领军企业。PaaS也依然扮演着游戏规则改变者的角色。

     

     

    PaaS的最新趋势与挑战


     

     

    随着企业的积极上云,新的多样化的需求和特征也随之表现出来,从以往单一的建设私有云到转变为公有云加私有云的混合云架构,并从多个云厂商采购异构资源的多云架构,企业的云架构正在逐步向混合多云,多元异构云等更为复杂的系统转变。

     

    IBM预测说,“Hybrid multi-cloud architectures will replace the “one-cloud-fits-all” approach”,在未来混合多云架构将会逐渐取代单一的云形态。并出现各种分类标准下的新形态云模型,如容器云,行业云等。

     

     

    这种现象,一方面来自于技术本身的多元化发展,另一方面,主要是由于很多企业在上云的初期,并没有建立完善的云机制,而是根据业务形态和增长需求选择不同的云及其供应商。在过去几年业务创新和上云的过程中,也逐渐形成了混合多云的IT环境,数据系统变得越来越庞大和复杂。这在一定程度上影响了后续业务的统一设计和规划,同时也给运维带来了很大的挑战。

     

    具体来说,比如缺乏统一的资源管理和分配回收机制,人员和权限系统稀松,整体的业务和系统架构过于分散,在运维中面临环境不标准,运维难度大,缺乏合适的技术人员,运维工作效率低,还有各类开源技术和软件带来更多的挑战。

     

    因此,从业务发展,成本优化,企业管理等多个角度来看,构建或者采用标准的IT PaaS 平台已成为企业发展的关键指标。

     

    那么如何构建标准的的可支持多元异构业务和IT架构的PaaS平台呢?

     

    这需要考虑企业应用的特征。一般在中小企业中,业务形态相对简单,一方面不需要复杂的体系,另一方面,业务领域尚未确定无法构建标准。最常见的是业务以托管或者SaaS的形态存在,无需资源层过多的成本投入。

     

    在中大型企业中,业务和IT技术已经俨然是密不可分的状态,一切业务变革和创新都离不开IT的支持,而业务面临的痛点,往往也会反映到IT系统的建设的挑战。一般整体的数据系统具有以下特点:

     

    01

    应用系统复杂、标准化程度低:在成长期,为了快速响应业务需求,往往忽略了长期规划,因此大部分企业在硬件环境、技术架构和研发规范等方面难以形成统一的标准。

     

    02

    系统体量大,关联复杂:大型企业信息系统往往系统众多,数据量大,系统之间往往有交叉。

     

    03

    安全管理要求高:大型企业对于业务连续性,管理流程规范程度,数据操作合法性,数据安全防护和服务保障方面往往有着更高的要求。

     

    04 

    开放开源自研发趋势:大型企业在业务发展过程中,为了逐渐实现自主可控,除了技术架构和组件使用开源以外,业务绝大多数是自主研发,但相对缺少专业的流程和机制,对于应用质量的管理比较缺乏。

     

    一款好的PaaS级解决方案必须能够友好地应对以上业务需求,同时为了应对运维管理面临的挑战,仅仅对于PaaS本身足够专业还是不足的,更要能够贯穿IT整个系统进行设计规划。在很多企业上云的过程当中, IT 部门开始为业务部门提供平台、培训、咨询和支持等服务,还负责整体治理, IT部门从“工厂式 交付” 向着 “服务提供商”的方向发展。数据的运营管理能力已经成为PaaS平台建设的关键能力。

     

     

    zCloud云管平台


     

     

    云和恩墨在过去10年的行业客户服务中,对于IT架构,数据架构有着深刻独到的见解。也一直根据企业的业务需求拓展自身业务领域,旨在为广大行业和企业级客户提供最及时最专业最有价值的服务和解决方案。针对以上的业务需求和挑战,我们独立研发了zCloud 多数据库云管平台。

     

    该平台主要具有以下两大属性:

    1、云管平台:资源的统一纳管,分配,度量,回收。实现人员(角色,权限,职能,岗位),基础架构资源(设备,架构,组件,版本)和管理(审批,协同,监管)的一体化管理

    2、自动智能化运维平台:对于企业IT系统做全生命周期的安全,容量,性能,高可用,容灾备份,成本,支撑业务,应用质量等全方位管控。实现标准化,自动化,智能化运维

     

    其基本功能和架构如下:

     

     

     

    以数据为核心,构建自顶向下的数据管理能力,包括数据交互,数据功能和模块封装,数据处理,以及数据承载。这构成了zCloud的核心逻辑体系。从硬件环境,虚拟化,数据库,中间件的支持,到上层业务接口和形态,zCloud完全支持多源异构,能够很好地应对企业的各种需求。

     

                      

    是数据平台,更是业务中台


     

     

    一直以来,PaaS层面临一个最大的挑战是,作为标准和规范的建立者,很多PaaS的服务供应商只允许企业按照平台的标准建立全新的系统,对架构进行重构。但企业的核心业务往往出于对连续性,性能等各方面的考虑,经不起太大的底层改造。因而对于上云,尤其是构建PaaS层平台服务一直望而生畏。

     

    我们在产品的设计和实现上,尽量遵循标准先行,为企业IT建设的架构设计,技术选型,硬件,工具和各类插件的选择建立规范,并支持主流的技术和组件类别。对于企业现有的IaaS层资源,无论是传统的本地运行环境,还是在云端,都有良好的兼容性,使得企业在迁云的过程中不需要太多的底层改造。现有的IaaS环境可以直接嵌入,作为平台的底层资源池。

     

    作为一款平台级别的产品,zCloud支持超大型客户IT环境和各类异构技术,和周边系统能够友好对接,在资源管理上,实现完全池化和云化,通过租户的方式对资源进行隔离,租户单元可由用户自定义,并支持跨网段资源分配。目前产品正在逐步实现组件化,能够与企业的应用管理平台和IaaS底层资源做良好的定制和集成,以平台或者以单独的功能模块都可以交付,为企业上云提供了极大的便利。

     

    另一方面,作为自动化运维平台,zCloud兼顾了数据系统从设计规划,建设实施,管理运维的整个生命周期中的所有主要任务,基于云和恩墨的数据服务经验为企业IT提供最高质量的保护和管理。包括:自动安装部署,监控告警,健康检查,高可用,备份恢复,容灾,安全管理,SQL质量管理,性能管理等各个维度。在每一个维度不断优化流程和机制,致力于实现标准化,自动化,智能化的数据资产运营。

     

     

    随着业务的发展以及企业自身IT能力的增强,行业的头部公司在IT能力相对过剩的情况下,逐渐探索通过IT能力的输出为同行业提供业务契合度极高的相关技术产品和服务。基于对行业业务的精通,加之在业务方向有相对的引导地位,这些头部企业在构建并输出IT能力的过程中是非常具有优势的。通过云管平台,真正打通底层数据和架构,让数据在最佳运营状态下更好地支撑业务需求。来自行业领军企业业务优势与专业数据管理能力的结合,正成为行业云的最佳生长环境。

     

    2016年,云和恩墨与某金融企业联合开发的金融云DBaaS平台,达到金融级要求的数据库平台,该平台运行在金融云IaaS平台之上,支持两地三中心的双活架构,为企业自身以及中小金融行业客户提供高可靠、高安全的数据库平台。一款“好用,用得起”的DBaaS平台帮助金融中小企业实现业务快速上云。

     

    IT系统和技术在企业中承担着越来越重要的角色。我们的使命,是帮助用户梳理现有资源,建设数据资源管理规范,让企业不为单一数据库束缚,也不被数据孤岛所割裂,让数据在集中统一的规划管理下稳健,敏捷支撑业务需求,并通过大数据和人工智能的应用助力企业业务的决策。

     

    以云管为基础,构建私有云公有云的混合能力,以数据为核心,建立多数据库的异构支撑能力。逐步实现真正平台化,中台化的服务共享支撑能力。

     

    想了解更多关于数据库、云技术的内容吗?

    快来关注“数据和云”公众号、“云和恩墨”官方网站,我们期待与大家一同学习和进步!

     

    truncate触发ORA-02266错误的解决过程

     

     

    (扫描上方二维码,关注“数据和云”公众号,即可查看更多科技文章)

    展开全文
  • PaaS云平台架构和运维管理C目录01020304分布式PaaS平台介绍传统企业PaaS设计和业务上云基于PAAS平台运维管理PaaS平台功能和构建第一章:分布式PaaS平台介绍开发和运维之间的困局开发团队:主要工作是编写业务所需的...
  • PaaS架构解析

    2021-10-13 10:39:26
    诸多大公司也纷纷推出自己的PaaS平台,比如Pivotal的CloudFoundry, IBM的Bluemix和Redhat的OpenShift等。其实在此之前, PaaS已经有很长一段时间的发展历程。在2007年,Salesforce最早发布force.com,其目的是支持第...
  • 中国移动PaaS平台技术选型和实践经验分享中国移动PaaS平台技术选型和实践经验分享中国移动PaaS平台技术选型和实践经验分享中国移动PaaS平台技术选型和实践经验分享中国移动PaaS平台技术选型和实践经验分享
  • GB∕T 35301-2017 信息技术 云计算 平台即服务(PaaS)参考架构
  • 基于微服务和Docker容器技术的PaaS平台架构设计
  • 读完这篇文章里你能收获到 - 在 Kubernetes 上最小化安装 KubeSphere
  • PaaS参考架构国标内容摘要

    千次阅读 2019-02-18 20:42:33
    推荐性PaaS国家标准GB/T 36327-2018于2019年1月1日开始执行,同时目前PaaS相关的标准还有国标GB/T 35301-2017,我们来摘要一下标准所关注的内容。
  • 文章基于轻量级容器技术和微服务架构,提出了一种新的云件Paa S平台,该平台可以在不修改传统软件的情况下,直接将软件部署到云端运行,并通过浏览器服务于终端用户。通过采用微服务架构设计,使得该云件平台具有较好的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,739
精华内容 14,295
关键字:

paas平台架构

友情链接: hardware.zip