关闭

基于微服务架构的云平台总体设计

标签: devopsdocker云平台
6022人阅读 评论(2) 收藏 举报

正好这段时间我们在封闭研发我们的新一代数字化云平台(theplatform),借此机会和大家分享一下我们的总体设计及思路:


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,因为设计的很多,我们第一个版本只有很短的周期,必须要有取舍,又要体现我们的理念


差不多初步设计就这样了,希望各位给出好建议!



1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:29877次
    • 积分:246
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:0篇
    • 译文:0篇
    • 评论:7条
    文章存档
    最新评论