×

扫描二维码登录本站

QQ登录

只需一步,快速开始

标签: 暂无标签
这10年来我一直从事中间件产品研发,从以前的UI设计器、开发工具到现在的大数据、云计算等,遇到的挫折其实并不多。但去年的DevOps产品研发,最终成果很难令人满意,到底是什么问题导致?凡事都讲天时地利人和,产品研发亦然,而作为DevOps产品架构设计者,我到底犯了哪些错误?在此,我会从架构、技术、团队等方面进行问题剖析、总结,希望能与各位大牛产生共鸣。
从去年6、7月份开始,我相继研发了普元新一代云平台(The Platform)0.1,0.2版本,预计今年年底会发布1.0版本。前两个版本都是围绕DevOps、CaaS、MicroService三个业务进行研发的,版本虽然已发布,但离既定目标尚有不短的距离,回过头来总结,我在总体设计这块犯下了6个错误,在这里与各位分享,希望能产生共鸣。
这里通过一张图,简单介绍一下平台架构:
产品以容器作为底层资源管理支撑,微服务架构作为运行支撑,形成了以三类PaaS(集成类、流程类、数据类)作为运行环境,DevOps作为全生命周期自动化支撑的云平台。
对于我们来说,希望做的是大生命周期的支撑,所以对于DevOps产品的定位如下(从产品定义到最终上线运维):
OK,回归主题,不知道各位在做大型产品的总体设计时,一般思路是怎样的?我们当时从五方面着手:
1. 概念先行。从概念模型着手,梳理产品中的核心实体对象,DevOps平台的核心是开发交付和运营反馈,具体如下:
2. 场景驱动。对DevOps业务场景进行梳理,定义平台相关角色,定义主流程。DevOps平台通过分工协作与质量管控,力求全生命周期的自助与自动,具体如下:
3. 模块划分。定义平台子系统(微服务),我们在设计时,一则是想DevOps平台本身采用微服务架构,二则是DevOps平台支撑微服务运行,最终平台形成了10个左右的子系统,具体:
上图的几个简写术语:SRM-软件资源管理,SPM-软件产品管理,SEM-软件环境管理,BPR-二级制仓库,DPR-可部署包仓库。
4. 团队分工。团队这块的划分采用了两个维度,一个是子系统责任制,一个是技术分层,将团队个人特长最大化,具体如下:
5. 规范约束。处理一些管理过程规范外,在开发规范上,定义了子系统之间的边界规范,以API和SPI的模式来实现,每个小团队与上下游团队共同制定和review接口设计,具体如下:
上面的配图是一些草图,不太严谨,我之前在另一个群分享过我们平台的总体设计,大家若对材料有兴趣,可联系我,也可从我们的公众号上获取。
从大面上粗看貌似没什么问题,但大家或许心里已经有疑问了,比如说:
1.    数据模型在哪儿?DevOps平台本身讲究工具链的整合,对于扩展性,尤其是数据库的扩展性设计要求非常高(大家有时间可看看Team Foundation Service、Rational Team Concert这些平台的扩展性设计,非常不错)
2.    DevOps平台本身采用微服务架构,同时支撑微服务在上面运行,难免会陷入一个鸡生蛋、蛋生鸡的问题,如何解决?
3.    开发架构上只是定义了一些子系统边界,对于DevOps平台具体的依赖产品或框架是怎么制定标准的?
4.    团队分工采用了两维设计,一些两维度冲突的地方是怎么解决的?
5.    ……
是的,这些都是问题,也正是这些问题以及我的经验不足,让我犯了标题中提到的6个错误:
错误1:概念耦合。最典型的就是没有将DevOpsCaaSMicroService拆分开来看。
这是现在业界的一个普遍现象,大家会看到,很多人把微服务,Docker,DevOps都放在一起谈。比如下面这些大会分享上的截图:
当然不是说这些作者本身概念混了,而是说现在的很多讲法,容易造成读者的误解。
事实上,这三者是独立的三个领域概念,DevOps的本质是:
而微服务是一种架构风格,难点在于开发规范与运维支撑。而容器呢,可以这么说,微服务架构给容器技术的风靡加了一把火:
所以,这三者完全是可以分开建设的,DevOps平台更应该关心多工具链及应用整合,异构环境的统一管理,流程的驱动支撑。
第一个错误给我的启示是:概念模型需要从领域着手,多领域需严格分开,当然,这也符合时下DDD倡导的设计模式。
错误2:关键设计未集中来做。最典型的问题就是数据模型(ER)的设计下放到每个子系统去设计。
业界现在有很多总体设计的方法,比如4+1模式(一般不带数据架构)、再比如togaf模式(一般包括数据架构),其实最关键的是哪种最适合现在的产品及团队。当时拆成小团队后,把数据模型的设计完全交给子团队在详设里去做了,造成了诸多设计不一致性。大家都知道,在DevOps这样的很难标准化的平台中,数据模型的扩展性设计要求非常高,比如对横表、拉链表、历史表的使用会特别频繁。
再者还有些细节问题,总体设计虽然定了表命名、列命名、主键类型、索引策略等规范,但是还是出现了一些问题,比如同样是某个实体的唯一代码,这边叫ID,那边叫CODE,还有两者做冗余都有的,造成API参数传递时,尤其是跨子系统传递时,参数命名很不一致,再者就是下游往上游系统返回数据时,上游系统还要做额外的映射处理。
第二个错误给我的启示是:在一些传统的管理域系统中,像ERP,OA这种,数据模型往往是重中之重,必须集中来做,完全扁平化的设计下放,是一个风险非常大的行为。
错误3MVP未深思熟虑,未采用最工程化方式来实现。
这应该是我最大的一个错误,对MVP的理解过于肤浅。MVP一般有很多路可走:
比如:你要解决交通问题,那可以先造一辆自行车,再造一辆三轮车,再造小汽车……
再比如:同样你要解决交通问题,你可以先造非常裸的小汽车(四轮子、发动机、无内饰、无空调、手动等),然后逐步加配件、升级系统……
上述的两个都是MVP,但却完全是不同的执行路径。所以对于DevOps平台的MVP之路,应该是什么样子?
我之前的理解:先做了一个比较裸的微服务框架,包括rpc调用,服务注册与发现,上下文处理,token处理等,基于这个框架来进行DevOps平台开发,同时在DevOps平台研发中,先做产品管理、持续构建和持续发布。
但上述这个做法忽略了一个关键问题,我们的最终目标是DevOps的全生命周期支撑,到底是先做生命周期中的部分阶段,还是先完成整个阶段的驱动,再丰富每个阶段的血肉。
现在看来,全生命周期打通才是最重要的,定义阶段与阶段间的输入输出,也许某些阶段还是手工方式,但不影响整个DevOps的理念的渗入和逐步精益的大原则。
同时,大家知道,作为第一个版本,采用一个全新的架构,而且是还不完善的架构(比如缺了微服务架构的数据一致性支撑能力),风险是很大的。更何况我们普元做了16年的中间件,很多技术平台和框架的积累,在DevOps产品研发中都没有使用,而是采用了纯开源模式新做,这一点大大违背了IT工程化的建设思路。
第三个错误给我的启示是:MVP并不是功能的MVP,是实践之路的MVP,每个产品都有自己的最核心理念,再小的MVP也要能阐述理念。MVP的实施要用最稳妥的方式,切勿激进,市场、尤其企业市场绝不会像很多互联网宣传那样,给你试对试错的机会,即使你的速度和反应再快也不会。
错误4:没有引入流程引擎作为底层支撑,更何况是我们有流程引擎成熟产品的前提下。
现在谈DevOps平台的最佳实践维度,很多会用这张图:
不难看出,流程部分是非常重要的部分,其实引入流程引擎的好处,不仅仅是用来做简单的状态流转(比如bug、任务等),更可以用流程引擎来编排不同子系统提供的能力,即使编排的都是自动活动。因为:
首先,流程引擎一般本身提供足够的API能力,统计分析能力,适配能力等,为后续优化、反馈、变更提供了足够的底层支撑。
再者,从扩展性来考虑,举例子,同样做敏捷,Agile、Scrum、CMMI流程,以及其workitem状态流都是有区别的,如果通过对各个模式的硬编码,后续的变更是非常麻烦的,同时还要建立在对这些模式的充分理解的前提下(说实话,现在的很多模式分支实在太多了),而流程的好处在于快速调整适应,同时,即使流程定义后变更很难,还可以用自由流等手段来实现,一般现在的流程引擎都是有自由流能力的,以前做过厂商,这种特殊能力通过编码实现的话还是非常难的,很难做的完善,尤其上下文的管理。
第四个错误给我的启示是:DevOps产品(这里说的是产品,不是某个企业的特定项目),一大难点在于流程差异性的屏蔽和流程快速调整的支撑,大到企业部门间协作流程,小到活动状态流转,所以流程引擎的引入会对产品的持续发展提供积极作用。
错误5:康威定律的实践问题,异地团队与子系统的结合方式有些欠妥。
以前一直和别人说康威,做着做着才发现自己的理解是多么片面。先说下我们的团队情况,我们的研发团队分在西安和上海两地,有一段时间甚至是三地(还有北京),整个团队偏新,之前共事较少。
在出现异地的时候,其实技术特长不应该作为分组的首选条件,因为这样很可能会出现某个小团队跨两地,这是一个很不好的状态,因为沟通才是异地的最大挑战。所以在分组之初,尽可能让异地的交集工作最少、沟通最畅,最理想的情况是做到两地分别只有一个接口人,其余人完全不存在异地沟通。
第五个错误给我的启示是:单管道模式虽然有瓶颈,但比起多管道模式来说,更易治理,所以异地协作我更推崇单管道模式。
错误6:架构师的参与度不足。
总体设计离最终落地往往都还有一段距离,这个距离是需要架构师在后续过程阶段去弥补的,这就是概念到落地的距离,也是很多架构师的瓶颈所在。
一个很形象的说法,架构师是做拍板的,要对任何决定负责。说这句话突然想到了最近的美国大选,从两个候选人的辩论中,感觉都挺缺乏担当的,呵呵,扯远了!
许多细节的设计是要逐步完善的,举个我们做的不好的例子,在Git库主干与分支的使用模式上,我们在前期VCS子系统设计时就没有考虑清楚,当时只考虑了常用TBD模式的支撑,后续架构师在这个子系统上的投入太少,使得后续在对客户需求的应答上能力缺口太大。既然提到版本控制库使用问题,有不少不错的blog大家可参考,比如阮一峰大侠的:
这里我有两个建议:
首先,架构师不要过早撤出项目。当然,很多架构师可能身兼数职,在某一个具体项目中的投入很难保障,如果是这样,只能说高层对这个产品的重视度不够,或者这根本就不是个明星产品,其造成风险会很大。
其次,架构师尽可能参与核心部分开发。前段时间圈里总是在吵CTO该不该编码的问题,我个人觉得CTO可不参与,但架构师还是要参与的,不能只是简单的预研、设计、验证等工作,容易造成与实际落地的脱节。
第六个错误给我的启示是:架构师作为现代IT中一个蛮有争议的角色,需主动寻求更多的价值点。而在DevOps产品研发中,作为架构师,需非常了解各工具链原理、整合方案等,才能有机串联整个平台。
现在,我们1.0版本的研发中,做了这样的一些调整,来应对上述的一些发现的问题。
·         组织架构的调整,拆成了独立的三部分来做,分成DevOps团队、容器云团队、微服务团队。
·         引入EOS(开发平台)、BPS(流程引擎),支撑平台下一个MVP的工程化交付。
·         概念模型到数据模型的总体设计,将DevOps分为产品管理、项目管理、交付中心、代码&构建、权限管理五部分。
·         不再自己杜撰需求(当然之前也不是杜撰的,只是与实际结合还不够紧密),结合灯塔客户的具体需求与状况,来辅助完成产品研发。
·         
·         团队分工,异地做一定牺牲,前期需求与设计阶段在一起办公,同时独立分出架构师,全职参与DevOps产品研发和实施。
对今天的分享做个总结,在DevOps产品研发中,因为总体设计不够充分,技术选型过于激进,对异地团队协作的困难预估不足,本身的参与度不够等问题,使得产品质量目标未能完全达到。目前已通过一定手段有效解决,并希望通过灯塔客户需求的实施,完成产品能力的改造与完善
顾伟原创





上一篇:顶级自动化测试助你选到最“好”工具
下一篇:用对了工具,CI/CD就容易了
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部