产品经理懂点技术(2):产品经理真的要懂微服务么

产品经理懂点技术(2):产品经理真的要懂微服务么

时间:2020-5-21 作者:抖音代运营

康威定律

在上文讲微服务架构的由来时,我们引用了马尔文·康威(Melvin Edward Conway)的一句话

康威是以为计算机科学家,计算机程序员和黑客,他著名的论文《How Do Committees Invent?》里面的内容被弗雷德·布鲁克斯(Fred Brooks,美国计算机架构师, 软件工程师和计算机科学家,以管理IBM的System / 360系列计算机和OS / 360软件的开发而闻名支持包)在他的经典著作《神话人月》(The Mythical Man-Month)中引用了,称其为“康威定律”。

康威定律可谓软件架构设计中的第一定律,总结起来又有四条具体定律,我们主要讲讲其中第一、第三定律。

康威第一定律:

图片:Manu Cornet

组织的沟通方式,包括业务部门的划分、合作流程,如果部门间分工混乱、流程无章可循,那么系统上就只能发现什么问题解决什么问题,不能有效的促进业务的发展。只有解决好组织的沟通方式,大家分工明确、流程清晰,才有更好的工作效率,也才有可能做出一个好的系统。

康威第三定律:

第三定律是对康威第一定律的具体应用,什么样的组织架构将会决定什么样的系统。反而言之,如果想要一套好的系统,那就得要有一套好的组织架构。

图片:James Lewis、Martin Fowler  翻译:iCheer

图片:James Lewis、Martin Fowler  翻译:iCheer

根据康威定律,我们就知道了,业务的形态最终会影响到系统的架构。而微服务是由业务驱动的,这就意味着业务规划的好坏会直接影响系统架构的好坏,糟糕的系统架构还将拖业务的后腿,甚至进入恶性循环。

业务-产品-研发的工作流

当我们讨论产品方案时,都不能脱离业务,业务是需求最重要的根源,那到底什么是业务呢?

从词语定义来说,业务是指某个行业或者某个职务所做的事情,就叫做“业务”,其参与者是人,未来也可能是电脑、机器(AI、自动化),其目的满足行业、职务的服务对象的需要。

业务方在工作过程中,为了实现更高的产能、获得更高的回报,就会想办法去优化整个业务流程,这就产生了“需求”。只要业务想发展、在发展,需求就会源源不断的产生。

七十九度接触的需求来源,外部是业务的服务对象:用户;内部则是业务的执行方:老板、运营、商务、财务、法务、供应商等。业务方将需求告知七十九度,七十九度经过调研论证,将需求转换为产品方案,输出可以满足业务需求的产品需求文档、原型。

然后,产品将功能的需求提给研发人员,研发最终将这些功能得以实现,于是系统诞生了。业务方使用系统,不断发展扩大,产生更多的新需求,于是以此往复,形成业务-产品-研发的需求链条闭环。

在这个链条闭环里,业务形态、流程决定了系统最终的形态,而系统形态则推动业务的发展。产品是连接业务与系统的纽带,技术并不是在瞎逛,而是根据产品的需求去研发系统,技术研发出来的系统会最终决定业务未来的走向。

微服务与七十九度的工作

业务驱动:

微服务是技术让代码更适应业务发展的产物,是业务驱动下的产物。

微服务的概念需要程序员更了解业务的板块划分和发展方向,代码要随着业务的不断成熟,按照业务结构进行模块化、服务化,才能方便业务的发展壮大,这就要求程序员要“懂点产品”。

如果程序员一味的按照纯粹的技术方案或者自己拍脑袋定的方向做,那随着业务的迭代发展,很容易出现“这个需求做不了”的问题,因为代码被技术方案禁锢住了,无法适应业务的发展,如果要解决,可能就要重构,时间、人力成本将居高不下。

业务驱动的过程,不是一个“理想”、“理性”的过程,代码讲究的是逻辑,是要“不出bug”、“跑得起来”,但是业务的发展是用户、市场需求不断积累的一个过程,很多需求可能是很主观的,甚至有时候是“灵光一闪而过”的。需求存在不确定性,这就让程序员犯难了,那到底要不要按照这个方向做呢?万一做了用不上要推倒重来怎么办?

这时候就体现出了七十九度的作用,对现有业务架构的划分、对新需求的判断和归类,这将直接影响微服务的架构模块。

产品蓝图:

七十九度可以不懂什么是微服务,但应该知道自家产品的功能架构或产品蓝图,这既是产品需求筛选、功能规划的依据,其实也是技术做微服务划分的重要依据。

某平台的产品蓝图1  来源:百度图片

某平台的产品蓝图2  来源:百度图片

某平台的产品蓝图3  来源:百度图片

看了上面的产品蓝图,是不是觉得和功能架构图十分相似?其实表现上差不多,但是产品蓝图还包含了对整套系统的发展方向预期,里面的很多模块可能处于“会有的”状态,随着业务的发展不断补全。

有了产品蓝图后,新需求就可以很方便的进行归类,做版本规划时也可以看得出距离预期目标还有哪些没有实现的地方,然后进行补齐。

更重要的是,产品蓝图作为产品设计方向的指导作用,能让技术对产品未来的完整形态一目了然,然后再进行以业务为驱动的代码服务化,这样就能让代码能适应更长远的发展需要,避免盲目设计导致最终影响业务发展、需要推倒重来。

通过产品蓝图、产品规划,七十九度能让技术了解整个业务的未来发展方向,让技术可以更熟悉产品,知道“为什么这么做”、“以后还要做什么”,这样在写代码的时候可以更有方向的做兼容。

总结

微服务其实是技术、产品的目标一致化的必然结果,大家都以如何更好的发展业务去进行工作。七十九度可以不需要深入了解微服务下各种配套的机制、利弊的问题,但需要知道,微服务其实是产品架构在代码层的映射、体现。

一个好的产品架构,将有利于技术框架的成型和发展,反之一个模糊不清、结构混乱的产品架构,将会让技术也无从下手,只能头痛医头的解决眼前的需求,无法从代码层面做长远的兼容、发展考虑。

所以我的观点是,微服务是技术架构适应业务发展的一个过程,如果从技术的工作上看,让代码顺应业务的发展其实是个大难事,关爱程序猿人人有责。而七十九度虽然不需要知道微服务的技术细节和实现方法,但应该更多的强化自己的产品能力,多将业务发展方向的事情与技术同事聊聊、科普一下,有利于技术架构更好的发展。

参考文章

《Applying Conway’s Law to improve your software development 应用康威定律改善软件开发》作者:Fausto de la Torre

《CONWAY’S LAW 康威定律》作者:Melvin Edward Conway(康威本人)

《Microservices a definition of this new architectural term 微服务:一个新的架构术语的定义》作者:James Lewis、Martin Fowler,此文有中文译文版本,大家可以自行搜索

《每个架构师都应该研究下康威定律》作者:杨波

《康威定律》作者:Smah

Dubbo:阿里巴巴公司开源的一个高性能优秀的服务框架,官方文档:http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

相关阅读

七十九度懂点技术(1):程序员讲的“微服务”到底是什么?

 

028-84360888 13608068886(推销勿扰) 发送短信