微服務(wù)是由業(yè)務(wù)驅(qū)動(dòng)的，這就意味著業(yè)務(wù)規(guī)劃的好壞會(huì)直接影響系統(tǒng)架構(gòu)的好壞，糟糕的系統(tǒng)架構(gòu)還將拖業(yè)務(wù)的后腿，甚至進(jìn)入惡性循環(huán)。

康威定律

在上文講微服務(wù)架構(gòu)的由來時(shí)，我們引用了馬爾文·康威（Melvin Edward Conway）的一句話

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

設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。

——Conway, 1967.

康威是以為計(jì)算機(jī)科學(xué)家，計(jì)算機(jī)程序員和黑客，他著名的論文《How Do Committees Invent？》里面的內(nèi)容被弗雷德·布魯克斯（Fred Brooks，美國計(jì)算機(jī)架構(gòu)師， 軟件工程師和計(jì)算機(jī)科學(xué)家，以管理IBM的System / 360系列計(jì)算機(jī)和OS / 360軟件的開發(fā)而聞名支持包）在他的經(jīng)典著作《神話人月》（The Mythical Man-Month）中引用了，稱其為“康威定律”。

康威定律可謂軟件架構(gòu)設(shè)計(jì)中的第一定律，總結(jié)起來又有四條具體定律，我們主要講講其中第一、第三定律。

康威第一定律：

Communication dictates design

組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來

圖片：Manu Cornet

組織的溝通方式，包括業(yè)務(wù)部門的劃分、合作流程，如果部門間分工混亂、流程無章可循，那么系統(tǒng)上就只能發(fā)現(xiàn)什么問題解決什么問題，不能有效的促進(jìn)業(yè)務(wù)的發(fā)展。只有解決好組織的溝通方式，大家分工明確、流程清晰，才有更好的工作效率，也才有可能做出一個(gè)好的系統(tǒng)。

康威第三定律：

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

線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性

筆者補(bǔ)充：homomorphism的中文翻譯是同晶（型）的意思。異質(zhì)同態(tài)就是外在不一樣，但是本質(zhì)結(jié)構(gòu)類似或一樣的意思。

第三定律是對(duì)康威第一定律的具體應(yīng)用，什么樣的組織架構(gòu)將會(huì)決定什么樣的系統(tǒng)。反而言之，如果想要一套好的系統(tǒng)，那就得要有一套好的組織架構(gòu)。

圖片：James Lewis、Martin Fowler? 翻譯：iCheer

圖片：James Lewis、Martin Fowler? 翻譯：iCheer

根據(jù)康威定律，我們就知道了，業(yè)務(wù)的形態(tài)最終會(huì)影響到系統(tǒng)的架構(gòu)。而微服務(wù)是由業(yè)務(wù)驅(qū)動(dòng)的，這就意味著業(yè)務(wù)規(guī)劃的好壞會(huì)直接影響系統(tǒng)架構(gòu)的好壞，糟糕的系統(tǒng)架構(gòu)還將拖業(yè)務(wù)的后腿，甚至進(jìn)入惡性循環(huán)。

業(yè)務(wù)-產(chǎn)品-研發(fā)的工作流

當(dāng)我們討論產(chǎn)品方案時(shí)，都不能脫離業(yè)務(wù)，業(yè)務(wù)是需求最重要的根源，那到底什么是業(yè)務(wù)呢？

從詞語定義來說，業(yè)務(wù)是指某個(gè)行業(yè)或者某個(gè)職務(wù)所做的事情，就叫做“業(yè)務(wù)”，其參與者是人，未來也可能是電腦、機(jī)器（AI、自動(dòng)化），其目的滿足行業(yè)、職務(wù)的服務(wù)對(duì)象的需要。

業(yè)務(wù)方在工作過程中，為了實(shí)現(xiàn)更高的產(chǎn)能、獲得更高的回報(bào)，就會(huì)想辦法去優(yōu)化整個(gè)業(yè)務(wù)流程，這就產(chǎn)生了“需求”。只要業(yè)務(wù)想發(fā)展、在發(fā)展，需求就會(huì)源源不斷的產(chǎn)生。

產(chǎn)品經(jīng)理接觸的需求來源，外部是業(yè)務(wù)的服務(wù)對(duì)象：用戶；內(nèi)部則是業(yè)務(wù)的執(zhí)行方：老板、運(yùn)營、商務(wù)、財(cái)務(wù)、法務(wù)、供應(yīng)商等。業(yè)務(wù)方將需求告知產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理經(jīng)過調(diào)研論證，將需求轉(zhuǎn)換為產(chǎn)品方案，輸出可以滿足業(yè)務(wù)需求的產(chǎn)品需求文檔、原型。

然后，產(chǎn)品將功能的需求提給研發(fā)人員，研發(fā)最終將這些功能得以實(shí)現(xiàn)，于是系統(tǒng)誕生了。業(yè)務(wù)方使用系統(tǒng)，不斷發(fā)展擴(kuò)大，產(chǎn)生更多的新需求，于是以此往復(fù)，形成業(yè)務(wù)-產(chǎn)品-研發(fā)的需求鏈條閉環(huán)。

在這個(gè)鏈條閉環(huán)里，業(yè)務(wù)形態(tài)、流程決定了系統(tǒng)最終的形態(tài)，而系統(tǒng)形態(tài)則推動(dòng)業(yè)務(wù)的發(fā)展。產(chǎn)品是連接業(yè)務(wù)與系統(tǒng)的紐帶，技術(shù)并不是在瞎逛，而是根據(jù)產(chǎn)品的需求去研發(fā)系統(tǒng)，技術(shù)研發(fā)出來的系統(tǒng)會(huì)最終決定業(yè)務(wù)未來的走向。

微服務(wù)與產(chǎn)品經(jīng)理的工作

業(yè)務(wù)驅(qū)動(dòng)：

微服務(wù)是技術(shù)讓代碼更適應(yīng)業(yè)務(wù)發(fā)展的產(chǎn)物，是業(yè)務(wù)驅(qū)動(dòng)下的產(chǎn)物。

微服務(wù)的概念需要程序員更了解業(yè)務(wù)的板塊劃分和發(fā)展方向，代碼要隨著業(yè)務(wù)的不斷成熟，按照業(yè)務(wù)結(jié)構(gòu)進(jìn)行模塊化、服務(wù)化，才能方便業(yè)務(wù)的發(fā)展壯大，這就要求程序員要“懂點(diǎn)產(chǎn)品”。

如果程序員一味的按照純粹的技術(shù)方案或者自己拍腦袋定的方向做，那隨著業(yè)務(wù)的迭代發(fā)展，很容易出現(xiàn)“這個(gè)需求做不了”的問題，因?yàn)榇a被技術(shù)方案禁錮住了，無法適應(yīng)業(yè)務(wù)的發(fā)展，如果要解決，可能就要重構(gòu)，時(shí)間、人力成本將居高不下。

業(yè)務(wù)驅(qū)動(dòng)的過程，不是一個(gè)“理想”、“理性”的過程，代碼講究的是邏輯，是要“不出bug”、“跑得起來”，但是業(yè)務(wù)的發(fā)展是用戶、市場需求不斷積累的一個(gè)過程，很多需求可能是很主觀的，甚至有時(shí)候是“靈光一閃而過”的。需求存在不確定性，這就讓程序員犯難了，那到底要不要按照這個(gè)方向做呢？萬一做了用不上要推倒重來怎么辦？

這時(shí)候就體現(xiàn)出了產(chǎn)品經(jīng)理的作用，對(duì)現(xiàn)有業(yè)務(wù)架構(gòu)的劃分、對(duì)新需求的判斷和歸類，這將直接影響微服務(wù)的架構(gòu)模塊。

產(chǎn)品藍(lán)圖：

產(chǎn)品經(jīng)理可以不懂什么是微服務(wù)，但應(yīng)該知道自家產(chǎn)品的功能架構(gòu)或產(chǎn)品藍(lán)圖，這既是產(chǎn)品需求篩選、功能規(guī)劃的依據(jù)，其實(shí)也是技術(shù)做微服務(wù)劃分的重要依據(jù)。

產(chǎn)品藍(lán)圖（Product Roadmap）是描述產(chǎn)品可能的發(fā)展方向，統(tǒng)一利益相關(guān)者的意見，計(jì)算產(chǎn)品開發(fā)預(yù)算的強(qiáng)大工具。 但是，想要作出切實(shí)有效的藍(lán)圖并不容易，尤其是在意外變化頻頻的敏捷環(huán)境中。

——《創(chuàng)建敏捷產(chǎn)品藍(lán)圖的十個(gè)技巧》-carlosmeya

Roadmap通常翻譯為“路線圖”或“藍(lán)圖”，目前并沒有一個(gè)公認(rèn)的定義。在這里，我們認(rèn)為Roadmap是產(chǎn)品經(jīng)理進(jìn)行產(chǎn)品管理的一個(gè)中長期規(guī)劃，也稱路標(biāo)規(guī)劃。
為什么要做Roadmap？簡單說就是，心中有數(shù)。

某平臺(tái)的產(chǎn)品藍(lán)圖1? 來源：百度圖片

某平臺(tái)的產(chǎn)品藍(lán)圖2? 來源：百度圖片

某平臺(tái)的產(chǎn)品藍(lán)圖3? 來源：百度圖片

看了上面的產(chǎn)品藍(lán)圖，是不是覺得和功能架構(gòu)圖十分相似？其實(shí)表現(xiàn)上差不多，但是產(chǎn)品藍(lán)圖還包含了對(duì)整套系統(tǒng)的發(fā)展方向預(yù)期，里面的很多模塊可能處于“會(huì)有的”狀態(tài)，隨著業(yè)務(wù)的發(fā)展不斷補(bǔ)全。

有了產(chǎn)品藍(lán)圖后，新需求就可以很方便的進(jìn)行歸類，做版本規(guī)劃時(shí)也可以看得出距離預(yù)期目標(biāo)還有哪些沒有實(shí)現(xiàn)的地方，然后進(jìn)行補(bǔ)齊。

更重要的是，產(chǎn)品藍(lán)圖作為產(chǎn)品設(shè)計(jì)方向的指導(dǎo)作用，能讓技術(shù)對(duì)產(chǎn)品未來的完整形態(tài)一目了然，然后再進(jìn)行以業(yè)務(wù)為驅(qū)動(dòng)的代碼服務(wù)化，這樣就能讓代碼能適應(yīng)更長遠(yuǎn)的發(fā)展需要，避免盲目設(shè)計(jì)導(dǎo)致最終影響業(yè)務(wù)發(fā)展、需要推倒重來。

通過產(chǎn)品藍(lán)圖、產(chǎn)品規(guī)劃，產(chǎn)品經(jīng)理能讓技術(shù)了解整個(gè)業(yè)務(wù)的未來發(fā)展方向，讓技術(shù)可以更熟悉產(chǎn)品，知道“為什么這么做”、“以后還要做什么”，這樣在寫代碼的時(shí)候可以更有方向的做兼容。

總結(jié)

微服務(wù)其實(shí)是技術(shù)、產(chǎn)品的目標(biāo)一致化的必然結(jié)果，大家都以如何更好的發(fā)展業(yè)務(wù)去進(jìn)行工作。產(chǎn)品經(jīng)理可以不需要深入了解微服務(wù)下各種配套的機(jī)制、利弊的問題，但需要知道，微服務(wù)其實(shí)是產(chǎn)品架構(gòu)在代碼層的映射、體現(xiàn)。

一個(gè)好的產(chǎn)品架構(gòu)，將有利于技術(shù)框架的成型和發(fā)展，反之一個(gè)模糊不清、結(jié)構(gòu)混亂的產(chǎn)品架構(gòu)，將會(huì)讓技術(shù)也無從下手，只能頭痛醫(yī)頭的解決眼前的需求，無法從代碼層面做長遠(yuǎn)的兼容、發(fā)展考慮。

所以我的觀點(diǎn)是，微服務(wù)是技術(shù)架構(gòu)適應(yīng)業(yè)務(wù)發(fā)展的一個(gè)過程，如果從技術(shù)的工作上看，讓代碼順應(yīng)業(yè)務(wù)的發(fā)展其實(shí)是個(gè)大難事，關(guān)愛程序猿人人有責(zé)。而產(chǎn)品經(jīng)理雖然不需要知道微服務(wù)的技術(shù)細(xì)節(jié)和實(shí)現(xiàn)方法，但應(yīng)該更多的強(qiáng)化自己的產(chǎn)品能力，多將業(yè)務(wù)發(fā)展方向的事情與技術(shù)同事聊聊、科普一下，有利于技術(shù)架構(gòu)更好的發(fā)展。

參考文章

《Applying Conway’s Law to improve your software development 應(yīng)用康威定律改善軟件開發(fā)》作者：Fausto de la Torre

《CONWAY’S LAW 康威定律》作者：Melvin Edward Conway（康威本人）

《Microservices a definition of this new architectural term 微服務(wù)：一個(gè)新的架構(gòu)術(shù)語的定義》作者：James Lewis、Martin Fowler，此文有中文譯文版本，大家可以自行搜索

《每個(gè)架構(gòu)師都應(yīng)該研究下康威定律》作者：楊波

《康威定律》作者：Smah

Dubbo：阿里巴巴公司開源的一個(gè)高性能優(yōu)秀的服務(wù)框架，官方文檔：http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

相關(guān)閱讀

產(chǎn)品經(jīng)理懂點(diǎn)技術(shù)（1）：程序員講的“微服務(wù)”到底是什么？

#專欄作家#

iCheer，公眾號(hào)：云主子，人人都是產(chǎn)品經(jīng)理專欄作家。房地產(chǎn)/物業(yè)行業(yè)產(chǎn)品經(jīng)理，Python編程愛好者，養(yǎng)貓發(fā)燒友。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議