微服务怎么快速迭代（产品经理懂点技术）

微服务是由业务驱动的，这就意味着业务规划的好坏会直接影响系统架构的好坏，糟糕的系统架构还将拖业务的后腿，甚至进入恶性循环。

康威定律

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

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

设计系统的架构受制于产生这些设计的组织的沟通结构。

——Conway, 1967.

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

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

康威第一定律：

Communication dictates design

组织沟通方式会通过系统设计表达出来

图片：Manu Cornet

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

康威第三定律：

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型组织架构间有潜在的异质同态特性

笔者补充：homomorphism的中文翻译是同晶（型）的意思。异质同态就是外在不一样，但是本质结构类似或一样的意思。

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

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

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

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

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

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

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

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

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

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

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

微服务与产品经理的工作

业务驱动：

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

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

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

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

这时候就体现出了产品经理的作用，对现有业务架构的划分、对新需求的判断和归类，这将直接影响微服务的架构模块。

产品蓝图：

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

产品蓝图（Product Roadmap）是描述产品可能的发展方向，统一利益相关者的意见，计算产品开发预算的强大工具。 但是，想要作出切实有效的蓝图并不容易，尤其是在意外变化频频的敏捷环境中。

——《创建敏捷产品蓝图的十个技巧》-carlosmeya

Roadmap通常翻译为“路线图”或“蓝图”，目前并没有一个公认的定义。在这里，我们认为Roadmap是产品经理进行产品管理的一个中长期规划，也称路标规划。 为什么要做Roadmap？简单说就是，心中有数。

某平台的产品蓝图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）：程序员讲的“微服务”到底是什么？

本文由 @iCheer 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

,