换公司已经有几个月的时间，现在更多的时间是在思考公司的PAAS平台的设计，这里将最近的一些思考整理出来，分享下自己的一些胡思乱想, 欢迎各位大佬指正其中的不足，也算是对这一段时间的总结吧

1.Paas的运行时与中间件



（图片取自网上，非本人原创）这是从网上找到一个关于IAAS、PAAS、SAAS最典型的一张图了，从图上我们可以看出相对于IAAS层而言PAAS层多了两个很重要的东西就是中间件和运行时，业务研发者只需要关注应用和数据，即可以完成对应应用的开发

1.1 运行时

在公司的PAAS平台建设中通常会提供到一个基础的平台ARP(Applications Running Platform)即应用运行平台，通过该平台支持公司的业务应用的运行，同时也是与公有云PAAS差异最大的地方，在这一层我们可以落地更多的公司的标准与规范，同时根据公司的需要进行数据的整合，这才是私有PAAS最大的意义



看上去很简单的运行时个人理解才是paas平台中最负责的设计之一，在PAAS里面有承上启下的意义，对下运行时的设计将底层的操作系统和服务器完全屏蔽掉，同时将各种基础设施平台细节进行隐藏，对上提供面向应用的环境，提供一键式的无感的运行环境支持

1.2 中间件

中间件泛指的就是各种基础服务，比如mysql、redis、mq、kafka、hbase等等，还包括公司自研的各种基础服务，通过这些服务应用研发可以更关注业务代码编写本身，而不需要对底层的各种依赖进行相应的调研测试，只需要使用PAAS平台提供的功能即可

中间件的接入在很多人感觉来看就是crud的操作，其实这只是面向用户使用层的方式，用户通过购买或者工单来完成对应基础设施的诉求。PAAS里面的中间件个人理解还有两层含义，1）稳定性：中间件通常都会有着极高的可用性，对中间件的接入，运维要关注其相应的规范并将其服务化，同时观测其稳定性，毕竟运维的核心工作之一就是稳定性； 2）IAC， 通过基础设施即代码的设计，将应用相关联的服务组件配置进行统一管理，后续如果要做迁移或者多环境部署，则就只需要重新拷贝一份即可

接下来我们聊另外的一个跟运维相关的东西-Devops

2. DevOps中的全链路与数据

Devops也是现在做运维大家老生常谈的一个东西了，我一直比较喜欢一个老师的观点，Devops本质上其实就做三件事：1.解耦 2.研发效能提升3.管理，不过我们今天只聊两个：全链路与数据流动

2.1 全链路



（图片取自网上，非本人原创）Devops是一个很大的概念， 在大多数的devops产品和系统里面，都强调端到端、数据化、持续度量运营的概念，首先是端到端，从需求提出开始，到设计、编码、持续集成、持续交付、持续部署、持续运营等全流程， 基本上也就涵盖了运维和研发的全流程

2.2 数据流动



数据流动是Devops从工具到平台的一个重要的衡量指标，根据阶段我将Devops流程里面数据流动分为了两个阶段：解耦与提升效能阶段、管理阶段。1）解耦与提升效能阶段：这个阶段主要是指的研发从接收到需求到持续集成、持续交付、持续部署三个核心阶段，该阶段数据流动的主要价值是提升效率、保证稳定性，同时最大程度进行工程解耦2）管理阶段：管理又可以细分为两个小阶段：运营管理与需求管理，运营管理是主要保证成本，即确保应用的资源利用率在一个合理的范围内，需求管理则是根据运营数据来进行需求迭代是否合理，从而避免因为Devops带来的研发效能提升的浪费

3. 私有Paas平台的思考

平台目前只完成了基础的功能设计，

3.1 应用PAAS

在进行第一版Paas设计的时候，其实并没有想设计成后来的样子，更多的只是想做一个应用管理PAAS， 结合上面的Devops思想，去构建公司的CICD流水线，实现研发从应用创建、环境部署、资源申请、中间件申请、持续集成、持续交付、持续部署的Devops的半个流程，然后通过oam进行应用元数据的管理

姑且这个版本就叫做APAAS, 其实整个建设部分只做了Devops部分链路的打通但是并没有做对应的数据流动，不过同时也做到了应用元数据管理、基础服务的服务化，我相信很多基于k8s做这件事情的人，都觉得这事应该并不是太难，笔者在此处思考时间3周+

3.2 仿品思考

现在的很多运维产品都很成熟，比如像蓝鲸、优维这两款产品一直陪伴着我做运维开发的日子，不过我一直都明白一件事这两个产品就只能拿过来用借鉴里面的思想，但是如果是要仿一个，老大铁定会先开掉我。

而且这两款产品其实已经是Saas了，根据公司的现状已经有了部分系统，虽然没有商业产品的成熟，但是如果想引进一个外部的商业产品，则会直接颠覆现状的运维体系和生态，我也一定会被开掉。

这两款产品的思考过程中其实让我想明白一件事就是我一定要先交付一个可用的Saas，在兼容现有运维体系下面，交付一个更上层的可用，而这个应用要能完成我上面提到的Paas与Devops的关键点：1）运行时：结合公司IAAS和容器平台，提供面向应用的运行时托管服务2) 全链路: 实现研发从应用创建、环境部署、资源申请、中间件申请、持续集成、持续交付、持续部署的Devops的半个流程

3.3 思考误区

思考这件事本身是一个尝试寻找结果的过程，思考PAAS本质也是如此，之前一直是基于K8s的Paas来思考，可是慢慢发现这是一个极大的误区，K8s抹掉了太多在Paas平台的东西(k8s底层设计)，在这个基础上如果再去思考PAAS其实就好比井底之蛙，其实看到的只是上层基于k8s的应用，而不是PAAS平台本身，我举个例子，如果我们把K8s定位成一个Paas基座(其实也有Saas功能)，那我们所有的ci、cd、Deployment、日志、监控等等其实都可以理解为其上的一个应用，我们将这些应用进行整合，构建我们的应用托管环境，那Paas平台提供的弹性、按需使用、故障自愈等基础功能，你还知道嘛？

3.4 平台应用

在蓝鲸里面用户可以基于平台完成上层Saas应用的开发，同时托管到蓝鲸，蓝鲸提供Paas的能力，而在优维里面也有对标的微应用，从这个角度来看其实我们所有的运维操作都可以分为平台和应用两部分

应用在运维PAAS平台里面主要是完成某个业务功能的具体的服务，应用可以利用平台提供的基础服务和平台服务构建上层完成某个具体场景功能的构建平台在我理解可以分为两层含义：1）Paas平台即提供对应的应用托管和基础服务 2）对底层基础服务的封装整合到当前平台中

3.5 数据流动

在进行服务整合集中化存储的时候，很大的一个问题就是数据一致性问题，因为会涉及到多个系统多份数据，那如何解决这个问题呢？借住分布式的思想，这个问题其实很好解决，就找个集中存储哇，就跟你用zk/etcd进行分布式协调一样，然后将私有的状态数据由各个服务自己进行存储

3.6 初版Paas



在Paas设计的时候我并没有按照组件来划分，而是根据场景结合上面提到的平台应用的概念进行设计的，首先我将整个系统建设分为三个服务体系：Devops服务、运维服务、基础服务；

Devops服务：就是我们上面提到的第一个版本应用PAAS，同时我们也只做这一部分，只有当这部分达到稳态的时候，才会进行后续部分建设；

基础服务：建设是提供Paas偏Saas的相关功能，即提供数据相关的功能，这样后续就只需要进行应用开发即可，平台提供基础的数据能力

运维服务：将运维能力服务化，同时对外提供平台层和应用层的功能，主要是为了满足公司运维的各种日常操作和运维场景，通过标准化运维将各种操作进行统一标准，减少误操的概率，同时将运维专家经验进行落地，并提供数据分析的功能，为运维数字化转型提供基础的数据

在现在的设计中打乱了正常的Devops平台的建设，进行一些细粒度的拆分，希望能够让老板们短时间看到对应的产出，看到运维数据化带来的收益，希望未来能有效果，同时将对应的规范和标准化落地到新的流程和系统中，将运维的经验进行平台化产出，推动公司的运维数字化转型

4. 未完待续

运维数字aaaaa化转型最大的问题就是思维的转变，很多运维平台建设都是烟囱式的，修修补补。数字化建设除了要解决这些眼前的问题还要思考未来，就像Devops中的不确定性与确定性一样，为什么要快速交付，因为不确定是否是市场要的，为什么要提高确定性，因为要尽可能保证安全、稳定的产品，Paas平台建设本质也是这样，快速向领导交付可用产品确定是不是领导要的产品

运维数字化的结果是共赢，运维开发团队提供基础的平台功能，运维将自己的运维经验进行场景化应用落地，这样就会有更多的数据，更多的场景应用，然后结合行业运维经验，就可以构建独一无二的行业数字化平台，通过行业场景+数据，才是私有Paas平台真正的竞争力，所以在运维PAAS平台建设中，运维可能才是最重要的推动者，而不是研发

平台建设的思考就先写这一篇，后面还是会继续分享一些云原生系统设计方面的东西，好好在思考下一些技术设计的实现与设计，毕竟一切设计都得落地

云原生学习笔记地址:  https://www.yuque.com/baxiaoshi/tyado3微信号：baxiaoshi2020 公共号: 图解源码