一、软件工程能力主要体现:
二、PaaS 平台的本质
三、PaaS 平台的总体架构
四、PaaS 平台的生产和运维
五、分布式系统解决方案总结：
一、软件工程能力主要体现:
第一，提高服务的 SLA。所谓服务的 SLA，也就是我们能提供多少个 9 的系统可用性，而每提高一个 9 的可用性都是对整个系统架构的重新洗礼。而提高系统的 SLA 主要表现在两个方面：
高可用的系统；
自动化的运维。
故障是常态，如果没有自动化的故障恢复，很难提高服务的 SLA。
第二，能力和资源重用或复用。
软件模块的重用；
软件运行环境和资源的重用。
两个重要的能力：“软件抽象的能力”（找出通用的软件模块或服务）“软件标准化的能
力”（使用统一的软件通讯协议、统一的开发和运维管理方法），这样能让整体软件开发运维的能力和资源得到最大程度的复用，从而增加效率。
第三，过程的自动化。
软件生产流水线；
软件运维自动化。
CI/CD 的 DevOps 式的自动化，生产环境中的软件进行自动化运维。这三个本质，和分布式的技术点是高度一致的，也就是下面这三个方面的能力：
分布式多层的系统架构。
服务化的能力供应。
自动化的运维能力。
这些目标都完美地体现在 PaaS 平台上。
PaaS 平台把东西给串联起来。
二、PaaS 平台的本质
分布式、服务化、自动化部署、高可用、敏捷以及分层开放的特征，
并可与 IaaS 实现良好的联动。
下面这三件事是 PaaS 跟传统中间件最大的差别。
服务化是 PaaS 的本质。软件模块重用，服务治理，对外提供能力是 PaaS 的本质。
分布式是 PaaS 的根本特性。多租户隔离、高可用、服务编排是 PaaS 的基本特性。
自动化是 PaaS 的灵魂。自动化部署安装运维，自动化伸缩调度是 PaaS 的关键。
三、PaaS 平台的总体架构
用了 Docker+Kubernetes 层来做了一个“技术缓冲层”。如果没有 Docker 和 Kubernetes，构建 PaaS 将会复杂很多。当然，如果你正在开发一个类似PaaS 的平台，那么你会发现自己开发出来的东西会跟 Docker 和 Kubernetes 非常像。
调度层（iPaaS）：管理和运维能力层
能力层（aPaaS）：提供实际能力的业务价值。
流量调度的接入模块（在两个相关的 PaaS 层之上）：流控、路由、降级、灰度、聚合、串联等等都在这里，包括最新的 AWS Lambda Service 的小函数等也可放在这里。这个模块应该是像 CDN 那样来部署的。图的两边分别是与运营和运维相关的。
完整的 PaaS 平台会包括以下几部分：
PaaS 调度层 – PaaS 的自动化和分布式对于高可用高性能的管理。
PaaS 能力服务层 – PaaS 真正提供给用户的服务和能力。
PaaS 的流量调度 – 与流量调度相关的东西，包括对高并发的管理。
PaaS 的运营管理 – 软件资源库、软件接入、认证和开放平台门户。
PaaS 的运维管理 – DevOps 相关的东西。（像 DockerHub 和 CMDB 的东西）
四、PaaS 平台的生产和运维
下面的图给出了一个大概的软件生产、运维和服务接入，它把之前的东西都串起来了。
左上开始软件构建，
1.进入软件资产库（Docker Registry+ 一些软件的定义），
2.走 DevOps的流程
2.1通过整体架构控制器进入生产环境（通过控制器操作 Docker+Kubernetes 集群
进行软件部署和生产变更）。
2.2.其中，同步服务的运行状态，并通过生命周期管理来拟合状态，
2.3服务运行时的数据会进入到相关应用监控（如图右侧部分所示）
2.4应用监控中的一些监控事件会同步到生命周期管理中，再由生命周期管理器来做出决定，通过控制器来调度服务运行。
3.当应用监控中心发现流量变化，要进行强制性伸缩时，它通过生命周期管理来通知控制系统进行伸缩。
4.左下是服务接入的相关组件，主要是网关服务，以及 API 聚合编排和流程处理。这对应于之前说过的流量调度和 API Gateway 的相关功能。
五、分布式系统解决方案总结：
1.完善的监控系统，以便对服务运行状态有全面的了解。
2.设计服务时要分析其依赖链；当非关键服务故障时，其他服务要自动降级功能，避免调用该服务。
3.重构老的软件，使其能被服务化；可以参考 SOA 和微服务的设计方式，目标是微服务化；使用 Docker 和 Kubernetes 来调度服务。
4.为老的服务编写接口逻辑来使用标准协议，或在必要时重构老的服务以使得它们有这些功能。
5.自动构建服务的依赖地图，并引入好的处理流程，让团队能以最快速度定位和恢复故障
6.使用一个 API Gateway，它具备服务流向控制、流量控制和管理的功能。
7.事务处理建议在存储层实现；根据业务需求，或者降级使用更简单、吞吐量更大的最终一致性方案，或者通过二阶段提交、Paxos、Raft、NWR 等方案之一，使用吞吐量小的强一致性方案。
8.模拟生产环境，乃至在生产环境中做灰度发布，增加测试强度；同时做充分的单元测试和集成测试以发现和消除缺陷；最后，在服务故障发生时，相关的多个团队同时上线自查服务状态，以最快地定位故障原因。
9.通过异步调用来减少对短响应时间的依赖；对关键服务提供专属硬件资源，并优化软件逻辑以缩短响应时间。
网友评论