正好这段时间咱们在封闭研发咱们的新一代数字化云平台（theplatform），借此机会和你们分享一下咱们的整体设计及思路：
sql
theplatform是一款基于微服务架构的DevOps容器云平台，设计主体分红了三个步骤：
1. 看问题：企业IT运营中的常见问题有哪些
2. 找方法：应对上述问题，常规手段有哪些
3. 作设计：这是今天的重点，导出概念模型、全景图、技术栈、工做分工、4视图等
其实对“看问题”和“找方法”咱们同事都有过详细描述，这里咱们先简单回顾一下
企业通常有信息流和业务流两段，尤为在业务流中，从需求到最终运营的各环节中，每一个环节都有趋于完善的方法和要解决的实际问题
好比：设计阶段，设计老是在纸面，真实开发时并不彻底依据，或者只有详细设计，缺乏优秀理念支撑
再好比：运营阶段，随着系统的增长，故障定位愈来愈困难，故障处理方法和积累的知识传递性不佳，对后续的产品发展指导性不强
数字化运营一样面临着诸多挑战
好比：业务语言和技术语言失真传递
再好比：因技术缘由致使的技术欠债致使包袱愈来愈重
再好比：因重复劳动、我的注意的一些问题，团队分工不合理，价值感不强等，致使人员变动影响巨大，同时束缚了知识工做者的创造力
那咱们看看有些什么解决方法呢？
最简单的，咱们遇到问题解决问题（被动的作法），将问题逐个击破
好比：对于关键事情依赖人的问题，咱们可让机器来作相关的事情，解放生产力
再好比：对于技术债务积压的问题，能够经过找合适的人，优秀的组织分工等慢慢改进
还能想到些什么方法或名词或理念？
还有不少颇有针对性的方法，好比敏捷，扁平组织，PDCA质量环
那咱们选择了DevOps这条路，来实现咱们理想的运营，同时以微服务架构为核心，协做与治理相结合，打造广义的DevOps
接下来就是咱们如何作设计了，我作设计的方法通常是从两个视角出发
平台视角很好理解，看全景，那人的视角是什么：
记得有位大拿说过，架构师必须有人员安排的权利，若是你不清楚团队的人的特色，或者无法调动最合适的资源，即便设计再牛的架构，也未必落得了地。
那咱们先看看如何推演第一个视角关心的全景图：
咱们分了三个比较重要的工做：
1. 场景拆分，用场景流程来发现须要改进的问题，而后用自助或自动的方式来解决问题，同时把这些解决方法划分到各领域系统，造成平台的支撑，这里场景拆的不少，有些草图，各位可简单浏览，就不用细看了，都是以前的初稿：
2. First app，或者你们习惯叫原型应用，这个实际上是很是重要的一环，咱们正是经过原型应用开发来验证场景，同时将咱们从设计到运营概括成了初版：23步完成，最终版：9步完成，具体步骤之后会有同窗分享
3. 源图宣讲，咱们提早小范围，大范围宣讲了不止30次，一是为了你们有统一的思想和理解，二是为了经过你们的验证反馈来优化咱们的源图
最终咱们导出了这张全景图：
这张图把DevOps工做者须要的服务能力（包括服务接入能力）、自动化处理能力、运营看板、遥测优化等作了定义，最终但愿造成一个有机的devops总体，固然，还要涵盖咱们以前的拆分场景，体现咱们firstapp中的步骤等
那咱们再看看如何推演第二个视角关心的组织架构工做的
一样是三点：
1. 基于全景图罗列技术，获得须要预研或对比的技术列表
2. 对人员能力进行划分，造成团队，要注意团队成员的互补性，这个前两天有同事已经介绍过了
3. 领域系统分层，将以前导出的各领域系统分类，让团队领取各系统，最终结合系统分层，造成有层次（上下游）的团队
最终结果是这样的：
这张图其实把团队分工、支撑领域系统和组件、须要掌握和使用的技术栈作了分解，结合这张图，后续咱们会有同窗来分享各个领域系统的设计和具体技术栈，这里我就不赘述了
那有了团队，有了全景图，咱们接着作啥呢？
咱们能够回到传统设计，概念模型，4+1视图，确实咱们也是这么作的
这图其实花了咱们最长时间来定稿，这里面概念看似简单，其实不少：
好比：部署包=介质包+配置，这和传统的CI和CD体系就有点不同
再好比：环境分开发、测试、预发、生产，咱们以为即便公有云上，也应该给客户将这些作物理或逻辑隔离，由于你们的配额需求不同，容器replication需求也可能不同
再好比：运维反馈，既然要作devops，那整个过程导出都应该能够有检查点插入，为运营提供有效数据，咱们把检查点至少分红了四类，包括过程的、安全的、性能的、业务的
有人说，整体设计期间，各小团队的工做有点难以开展，咱们除了培训外，同步，咱们的各团队已经开始了技术预研工做
这些工做实际上是须要结合各团队预研成果，补充进整体设计的
咱们前面提到了导出领域系统，我一直没讲有哪些，这里给出一个完整的：
上面部分是核心的，你们能够仔细看下，每一个系统都解决的是一个领域的问题：
好比：软件产品的管理，软件各阶段环境的管理，质量的管理，部署包、二进制包的管理，资源管理，监控中心，认证中心等
下面部分是完整的，按能力分层的，经过这个其实咱们就能够出逻辑架构图了
图上分了：
基础设施层：包括IaaS，CaaS，咱们分别是基于Openstack和Kubernetes的，上层有一层不一样环境的适配
基础服务层：包括服务管理与调度的基础能力，如注册中心，编排，伸缩漂移。还有一堆具体的企业级或互联网式的云服务
DevOps层：更多的是工做流程的串接，看板等文化的体现
再接着是部署视图（或者叫物理视图），咱们的公有云是要部署在阿里云上的（固然遇到了很多坑，后面有机会能够再分享，片子已经准备好了，呵呵）
图上最上面一层是用户的微应用，下层是咱们的管理节点，固然配置不同都是有所考虑的
再接着是运行视图（或者叫进程视图），这个比较简单写，咱们自己是分布式的管理，经过统一的门户来提供入口（只有门户和两个须要开放的进程放到DMZ）
运行过程统一了rest的资源风格，咱们全部的节点都是跑在容器中（本身开发本身吧）
再接着就是开发视图了
图上有两个典型项目：
一个是对外的能力包，定义了API，SPI
另外一个实际上是具体实现包，script是启停的钩子脚本，sql是数据库相关（包括回滚）
这里图上的例子是说，在咱们的模型中，若是A产品依赖B产品，那么咱们须要引入Adapter这个概念，A自己对外提供API能力，A的SPI须要B实现，但可能B已经有本身的API能力了，那中间Adapter实际上是作了SPI与API的适配（这块概念也不少，后面也会有同窗详细讲，咱们分布式设计的开发设计）
固然，咱们还作了其余的一些关键设计，包括：
像灰度发布，多租户这些，还有咱们的邀请客户（邀请码，邀请方式）的设计（这个会涉及到资源预置等方面，你们都懂的）
还有MVP，由于设计的不少，咱们第一个版本只有很短的周期，必需要有取舍，又要体现咱们的理念
差很少初步设计就这样了，但愿各位给出好建议！