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

康威定律

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

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

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

——Conway, 1967.

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

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

康威第一定律：

Communication dictates design

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

圖片：Manu Cornet

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

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

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

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

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

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

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

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

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

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

產(chǎn)品經(jīng)理接觸的需求來源，外部是業(yè)務(wù)的服務(wù)對象：用戶；內(nèi)部則是業(yè)務(wù)的執(zhí)行方：老板、運營、商務(wù)、財務(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ā)最終將這些功能得以實現(xiàn)，于是系統(tǒng)誕生了。業(yè)務(wù)方使用系統(tǒng)，不斷發(fā)展擴大，產(chǎn)生更多的新需求，于是以此往復(fù)，形成業(yè)務(wù)-產(chǎn)品-研發(fā)的需求鏈條閉環(huán)。

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

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

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

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

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

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

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

這時候就體現(xiàn)出了產(chǎn)品經(jīng)理的作用，對現(xiàn)有業(yè)務(wù)架構(gòu)的劃分、對新需求的判斷和歸類，這將直接影響微服務(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ù)做微服務(wù)劃分的重要依據(jù)。

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

所以我的觀點是，微服務(wù)是技術(shù)架構(gòu)適應(yīng)業(yè)務(wù)發(fā)展的一個過程，如果從技術(shù)的工作上看，讓代碼順應(yīng)業(yè)務(wù)的發(fā)展其實是個大難事，關(guān)愛程序猿人人有責(zé)。而產(chǎn)品經(jīng)理雖然不需要知道微服務(wù)的技術(shù)細(xì)節(jié)和實現(xiàn)方法，但應(yī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òu)術(shù)語的定義》作者：James Lewis、Martin Fowler，此文有中文譯文版本，大家可以自行搜索

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

《康威定律》作者：Smah

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

相關(guān)閱讀

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

#專欄作家#

iCheer，公眾號：云主子，人人都是產(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é)議