| 编辑推荐: |
本文主要介绍了新一代产品时的总体设计思路以及部分设计产物，希望对您的学习有所帮助。
本文来自于云社区，由火龙果软件Alice编辑、推荐。 |
|
主体分成了三个步骤：
1. 看问题：企业IT运营中的常见问题有哪些；
2. 找方法：应对上述问题，常规手段有哪些；
3. 做设计：这是今天的重点，导出概念模型、全景图、技术栈、工作分工、四视图等。
前两周在“缘起”和“从Devops开始”（详见公众平台历史消息）的相关PPT里，其实对“看问题”和“找方法”都有过详细描述，这里我们先简单回顾一下：
企业一般有信息流和业务流两段，尤其在业务流中，从需求到最终运营的各环节中，每个环节都有趋于完善的方法和要解决的实际问题。
比如：设计阶段，设计总是停留在纸面，真实开发时并不完全依据，或者只是具体设计，缺少理念支撑；
再比如：运营阶段，随着系统的增加，故障定位越来越困难，故障处理方法传递性不佳，对后续的产品发展指导性不强。
数字化运营同样面临着诸多挑战，比如：业务语言和技术语言失真传递；
再比如：因技术原因导致的技术欠债导致包袱越来越重；
再比如：因重复劳动、个人英雄的一些问题，导致人员变更影响巨大，同时束缚了知识工作者的创造力。
那我们看看有些什么解决方法呢？
最简单的，我们将问题逐个击破，比如：关键事情依赖人，我们可以让机器来做相关的事情，解放生产力；
再比如：技术债务积压，可以通过找合适的人，优秀的组织分工等慢慢改进。
大家还能想到些什么方法或名词或理念？
很多很多，比如敏捷，扁平组织，PDCA质量环……
我们选择了DevOps这条路来实现我们理想的运营，同时以微服务架构为核心，协作与治理相结合，打造广义的DevOps。
接下来就是我们如何做设计了，我做设计的方法一般是从两个视角出发。
平台视角很好理解——看全景，那人的视角是什么？
记得有位很牛的架构师说过，架构师必须有人员安排的权利，能够让合适的人做合适的事。如果你不清楚团队的人的特点，或者没法调动最合适的资源，即使设计再牛的架构，也未必落得了地。
那我们先看看如何推演第一个视角关心的全景图：
我们分了三个比较重要的工作：
1. 场景拆分，用场景流程来发现需要改进的问题，然后用自助或自动的方式来解决问题，同时把这些解决方法划分到各领域系统，形成平台的支撑，这里场景拆的很多，有一些草图，各位可简单浏览：
2. First app，或者大家习惯叫“原型应用”，这个其实是非常重要的一环。我们正是通过原型应用开发来验证场景，同时将我们从设计到运营归纳成了第一版：23步完成以及最终版：9步完成，具体步骤以后会有同学分享。
3. 源图宣讲，我们小范围、大范围宣讲了不止10次，一是为了大家有统一的思想和理解，二是为了通过大家的验证反馈来优化我们的源图。
最终我们导出了这张全景图：
这种图把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，因为设计的很多，我们第一个版本只有很短的周期，必须要有取舍，又要体现我们的理念。
附： 各 群 答 疑
Q1、群友1：一切皆为资源，如果有场景不是crud能解决的，不好抽象的业务怎么处理？
答：什么业务无法抽象资源？
群友1：当然所有的都可以抽象为资源，只是资源的粒度怎么统一。
答：你可以看一下男总那天分享的一切皆资源。粒度这个是按业务来看，一种资源体现一类能力。
Q2、群友：你们的监控这部分，除了有自己内部的监控系统，有没有从外部的对系统服务的监控呢？比如像newrelic这种。因为很多时候云系统内部一切正常，但是外面无法访问。
答：你说的对，我们现在主要也是内部监控出数据，缺少外部的，但外部监控的产品中我所了解的，都有这样那样的局限，我们很希望能找到合作伙伴一起来建设这部分能力。 |
