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

康威定律

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

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

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

——Conway, 1967.

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

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

康威第一定律：

Communication dictates design

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

圖片：Manu Cornet

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

康威第三定律：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務驅動：

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

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

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

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

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

產(chǎn)品藍圖：

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

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

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

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

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

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

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

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

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

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

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

總結

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

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

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

參考文章

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

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

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

《每個架構師都應該研究下康威定律》作者：楊波

《康威定律》作者：Smah

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

相關閱讀

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

#專欄作家#

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)許可，禁止轉載

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