雲時代的編程模式將會走向何方？

02-21

作者：騰訊雲佈道師黃希彤，摘自「中國雲計算大會」主題演講，有刪改

「微服務」

相信很多程序員們都與雲小哥面臨同樣的困擾，朋友圈近來頻頻被一個叫做「微服務」的概念給刷屏，各種「微服務實戰」「微服務架構指南」「微服務的優勢與不足」、「微服務的解析」文章層出不窮。

雲時代之前的編程模式

最早的時候，我們編程使用機器碼，然後是彙編語言，為什麼需要彙編語言，因為對人類大腦來說比0101更容易理解一些。

後來出現了高級語言，因為低級語言對人腦來講，還是太費解了，我們需要用更加接近人類語言的方式來描述問題。

然後出現了結構化編程，或者說模塊化編程。因為編程的語言我們雖然容易理解了，但是面對的問題還是太複雜，所以要把問題切割成小問題

模塊出現後，我們開始追求高內聚低耦合。因為就算分了模塊，人腦仍然無法思考太多的模塊之間錯綜複雜的關係，高內聚低耦合的模塊化讓我們可以一會兒思考模塊內部高內聚的邏輯而完全不考慮模塊之間的關係，一會兒又跳出來只思考模塊和模塊之間的關係，假設模塊會自己把事情都做對。

但是就算功能充分模塊化了，數據流還是太錯綜複雜，我們需要把數據也高內聚低耦合起來。

這個時候我們開始面相對象編程。這個圖的意思是說，面向對象的時候，我們編程總是比較高效的。

面向對象編程幫助我們把數據和對數據的操作封裝到內聚的模塊裡面，還提供了抽象、繼承、多態這樣一些新的思考問題的方式，於是我們這個原本只是設計來打獵種田的大腦，居然一下子可以駕馭非常複雜的業務邏輯，設計龐大的軟體系統了。

更容易被大腦理解的編程模式

但是人類是不會滿足的。我們永遠都試圖駕馭更大更複雜的系統，我們發展出了據說23種設計模式，還發展出了C／S，B／S，MVC，MVP，MVVM，SOA等一些架構模式，然後開始用這些概念吵架，並把它們做成面試題來考別人。

這一路發展過來，我們看到很明顯的一個趨勢是，我們總是追求更好的高內聚低耦合。相信在可以預見的未來，我們仍然會尋找更高內聚低耦合的編程模式。還有一個趨勢是，我們總是在追求更好的可重用性，試圖盡量少做重複的工作。另一個更加重要，更加本質化的趨勢是，我們其實總是在追求更容易被大腦理解的編程模式。

高類聚
低耦合
可重用
可理解

談一談微服務

我理解的微服務，不應該是一些新提出來的技術和名詞的堆砌。我們不應該一提到微服務就想起怎麼用Docker來實現、要採用幾層架構、有沒有其他高端大氣上檔次的技術可以運用，能不能快速開發持續交付。因為微服務應該是這樣一種思考：我現在面對的系統，是否能夠由一些「充分自治」的子系統來構成，也就是說，這些子系統應該可以獨立於我的大系統而獨立存在

子系統應該可以自己管理好自己，可以保證自己是健壯的，可以處理好自己的異常情況，在面對壓力的時候可以自己擴容而不需要我去擔心它的容量，在沒有壓力的時候應該自己縮容而不需要我去擔心它有沒有浪費資源。它應該不關心自己被誰使用，被越多使用方使用，越說明它有很好的可重用性，使用量越大，越說明它有可能產生規模效應，有可能用更低的平均成本提供更好的服務。

現在我們談論微服務的時候，往往僅僅只是一個原來的系統怎麼拆分成幾個微服務，這其實跟模塊化編程有什麼區別，我們60年前就在做這樣的事情了。雲時代之前，我做QQ空間的時候，我們也有獨立的相冊服務、日誌服務、留言板服務等等，但是我不認為這是雲時代我們在講的微服務。因為我們從來沒有試過把留言板拿出來獨立於QQ空間之外，讓它可以成為任何系統的留言板。

雲時代，我們究竟需要怎樣的微服務？

在雲的時代，我們需要的是這樣一種編程模式，我原來的系統怎麼拆分成幾個「通用」的微服務，進而讓它變成一種雲服務，不但我原來的系統可以使用它，我做出了這個服務以後，其他有類似需求的系統都可以重用它，不只是我的項目、我的公司的效率得到了提升，所有需要這個能力的項目都可以從中獲益。只有這樣，未來軟體開發才可以像今天的實體製造業一樣，在全球範圍內充分的分工合作，最大限度的提高人類的生產效率，而不只是我的項目的生產效率。

關於圓珠筆的故事

我們舉一個製造業的例子。大家知道，中國一年生產400億隻圓珠筆，卻製造不出圓珠筆的球珠。有人說中國作為一個制筆大國，這是中國的悲哀。聽說在總理的關懷下，有關部門還為此撥了6000萬元去研製這個小球，聽說還真的研製出了兩台製造設備。這從打破市場壟斷格局上看也許是有道理的。但是我們拋開國家主義，從全球分工的角度上看，筆珠這玩意美國也不造，還有很多中國造的東西美國都不造。全球只要一個國家甚至就一家工廠生產出全世界需要的筆珠，然後所有的國家不不再需要去造這個輪子，這不是微服務的理想境界嗎？

我們現在要開發一個新系統，就好比要去開一個新的圓珠筆廠一樣，把圓珠筆設計分成了幾個模塊後，去設計設計生產每一個組件，這不一定是有必要的。可能我們的創新在於這個筆的外形，或者可以把筆頭伸出來縮進去的新的棘輪系統的設計，而彈簧就跟彈簧廠買，筆珠就跟日本人進口，有什麼關係？如果我們這個棘輪系統設計的特別好，別人想在它的基礎上設計更好的圓珠筆，只要跟我們購買這個設計的專利授權合法使用，我又不吃虧。

互聯網產品領域的復用

類似的，我們今天要開發一個社交產品，我們的棘輪結構就是我們新的社交形態。但是做社交系統需要的筆尖可能是圖片上傳、下載、裁剪、縮放、甚至人臉識別這樣一個能力。當然這些我們也可以自己做，誰讓我們是碼農呢？但是如果你的產品形態真的很創新，很多用戶喜歡你的系統的時候，你的筆珠就可能成為制約你發展的命門，很多人拚命上傳下載圖片的時候，你的系統架構很可能會吃不消。甚至可能因為使用了ImageMagick處理圖片而被黑客拖了庫。

一個圓珠球是特別難做好的，但是我們都知道，中國有一個公司存儲處理了上萬億張的圖片，每天分發上百億張圖片，把這個球珠打磨的無比精緻，然後還把這個產品變成一個雲服務開放出來，那我們幹嘛非要去造這麼一個筆珠呢？

回到雲時代的編程模式上。在雲時代，我們基於微服務的設計理念來開發軟體，首先應該要考慮的是，有沒有現成的優秀的雲服務可以作為我系統需要的一個微服務，直接被我使用，比如我們剛剛講的圖片上傳下載裁剪縮放人臉識別。

如果沒有，那我們應該要考慮，我的系統需要的這個微服務，能不能變成一個通用的服務開放出來，如果可以這樣，我除了可以交付我的系統，也許還可以通過售賣我的微服務獲利，而更多有相同需求的開發者也可以用很低的成本跟我買這個筆珠來造他自己的圓珠筆，我們整個社會的軟體開發效率從而得到提升，創新成本因此也得以降低。

雲上的微服務

這個開發出來售賣的通用的微服務應該是充分自治的，很少人使用它的時候，它只耗費很少的計算資源，當他流行起來的時候，很多人需要它，它自己可以擴充自己的計算能力，而不會讓它的用戶在這個環節上遇到瓶頸。在使用高峰期過去的時候，它又應該自己進行縮容，避免浪費計算資源，所以很明顯，它應該運行在雲上。

當它更加流行的時候，原來我們做的那個大系統也不再重要了，這個微服務本身就可以讓我們過的很好，不管是我們自己按使用量賣還是把它賣給騰訊雲，前者的一個例子是我們從QQ空間發展出來的圖片服務通過騰訊雲開放出來，後者比較典型的案例可能是dnspod這樣一個服務。

總結

我們的軟體開發歷史上走過了機構化、面向對象、MVC、SOA等等開發模式。這些發展歷程共同的方向就是

1越來越高內聚低耦合
越來越好的可重用性
越來越容易被人類大腦理解

在雲時代，微服務是符合這3個大方向的新軟體開發模式。因此我認為下一代流行軟體開發模式很可能就是微服務。

我認為微服務不應該只是在一個系統裡面使用微服務架構去設計和開發，否則它們開出來也許就只能對一個系統有用。一個微服務不應該只是我們新設計的一個系統裡面的一個組件，而應該嘗試設計成使用者無關的充分自治的通用服務。一個微服務應該追求被更多的項目，甚至更多的公司重複使用。在我們基於微服務架構開發出來的那個大大系統消亡了以後，它的微服務可能還在繼續為其他系統發光發熱。

未來，我們基於微服務開發的軟體系統交付後，這些微服務不但有更多的機會被後續開發的系統重用，也許還有機會成為軟體公司新的收入來源，或者程序員新的創業項目和財務自由的機會。

我們現在開發軟體系統和改造舊系統的時候就應該充分的考慮到有哪些已經開放出來的雲服務可以作為我系統的微服務被我重用起來。而我又有哪些優良的微服務可以開放出來變成一個雲服務，造福更多的程序員兄弟。