寫在前面的話
在過去的幾天，我一直在咀嚼着關於微服務的相關概念，唯恐給自己落下一絲的不明白，也算是給自己採取的掃盲行動。畢竟也是在微服務圈子裏混的人了，不把概念吃透，還怎麼出去跟人家撕x呢？
講真，身邊結識的大牛也沒幾個，也沒有什麼高逼格的朋友圈，都是自己一路摸爬滾打過來的，想想幾年前的自己，真替自己感到心酸。
近來常有文章提到“微服務”還沒有一個相對官方的定義。
在我看來，就好像是「未婚先孕」。
在還沒有準備好的時候，突然就橫空出世了，而且還相當轟轟烈烈。
因此，我就尋思：我是不是該看看一些相對官方一點的文獻材料呢？到底有沒有定義？微服務到底是以一種什麼形態存在着？
不用懷疑，《Microservices》當屬最原汁原味的官方文獻材料了。
《Microservices》應該算是我讀過最短的論文了，整個過程（不含擴展閱讀內容），大約花了我1.5個小時，算是理解了其中心思想了。
如果中間不開小差的話，1個小時讀完差不多了。
1、確實沒有明確定義
這是我解開的第一個困惑：關於微服務，確實沒有官方正式的定義。
不僅如此，關於微服務的架構指導思想，或者說是最佳實踐，也並沒有出爐。
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services.
While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
……
We've seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications.
Sadly, however, there's not much information that outlines what the microservice style is and how to do it.
請原諒我以上不負責任的總結。
Ah...
知道這個意思就好！
不過，作者還是非常精煉地向我們描述了一下什麼是微服務：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
歸納起來，有以下幾點：
- 整個應用系統由若干個獨立運行的服務組成
- 服務之間有輕量級的通訊機制，通常是REST API
- 每個服務都有自己的業務邏輯，並且可以單獨部署
- 去中心化的服務管理機制
- 每個服務可以用不同的編程語言實現，使用不同的數據存儲技術
我們姑且認爲這就是微服務的定義吧！
畢竟「微服務」的首創是《Microservices》這篇論文的作者，並且也得到了業界廣泛的認可。
2、monolith v.s microservice
這篇論文除了「microservice」，另外還有一個高頻詞彙：「monolith」。
「monolith」可以理解成是傳統開發模式下的“單體應用”，在《我所瞭解的微服務》一文中有提及到，並且將其與微服務的模式做過簡單的對比。
在《Microservices》這篇論文中也不例外地將單體應用和微服務兩種開發模式做了比較詳細的對比。
結果呢？
當然不能讓monolith輸的這麼難堪呀！畢竟還是有很多公司採用這種開發模式的。
通篇讀下來，發現作者多次在強調單體應用的一個“軟肋”:
A small change requires the entire monolith to be rebuilt and deployed.
一次小變更，就意味着整個應用要重新打包，部署。對於其他沒有變更的業務模塊，將會受到不小的影響。
而微服務的優越性在於獨立打包，獨立部署，將服務之間的影響降到最低。
此外，文中就兩種開發模式的團隊管理進行了討論。
單體應用隨着應用規模的不斷擴大，團隊規模也隨之擴張，將團隊劃分成不同的業務線就是一個技術活，團隊成員之間的溝通協作也是一個巨大的挑戰，更不用說在這個團隊裏必須遵守統一的規約了。
微服務的高度自治的特性使得上述問題變得不那麼棘手了。各個服務之間的聯繫是鬆散的，可以用不同的編程語言實現，僅靠特定的協議相互調用。關於單個服務的規模大小，一篇擴展閱讀有提到過：《How big is a microservice?》
結論是：一個人，最多十幾個人，最後還是不確定，大概就是要我們視情況而定吧！
不過，正是因爲微服務的通信方式（lightweight mechanisms, often an HTTP resource API），導致了一部分的不確定性，也是應用出錯的場景之一。因爲服務之間的調用並不像單體應用那樣的本地方法調用，所以可能有各種因素導致各個服務之間溝通不暢。
3、一個重要的理念
文中提及了到了微服務的一個特性：
Products not Projects
—— 做產品，而不是做項目
這其實是一種開發理念的轉變。
大多數應用的開發都以軟件交付爲目的，開發完成後就交給運維部門管理了，項目團隊也隨之解散了。
而作者在文中強調，微服務的開發模式可不能這樣。
整個團隊應該跟隨着應用的全生命週期，開發者與微服務之間建立一種微妙的連接。
亞馬遜有一個著名的理念：
You build, you run it.
而後文的 Infrastructure Automation 一小節則提到了可持續集成與可持續交付，開發者通過自動化測試，自動化部署完成之後的工作。附上一張經典的pipeline示意圖：
basic-pipeline 來自《Microservices》
再後來的 Design for failure 一小節，提出了服務容錯，快速響應，自恢復，日誌記錄，實時監控等特性的重要性，幫助開發者快速定位並解決問題。
Microservice teams would expect to see sophisticated monitoring and logging setups for each individual service such as dashboards showing up/down status and a variety of operational and business relevant metrics.
這樣看來，不得不讓我聯想到DevOps！不過，談及微服務，DevOps、容器化都是不可迴避的話題。
4、微服務的未來
對於微服務的未來展望，作者還是說得很謙虛含蓄的。
作者也並沒有強調今後的設計理念應該要使用微服務，而是應該根據實際的業務需求，模塊劃分邊界以及團隊自身的技術水平等因素來制定。還是這句話：
但無論如何，微服務的架構風格值得每個公司認真去思考。畢竟相對於單體應用，微服務的架構還是利大於弊的。
據我目前的實踐經驗來看，實施這套理念還是需要有一支精幹的技術團隊，每一個人都具備一定的開發經驗，不然的話，是很難開展工作的。如果一旦決定採用微服務架構風格了，必然要以“小步快跑，迭代試錯”的節奏進入實施。
敏捷開發？我想是吧！
希望對你有所幫助。
THANKS！
每日干貨分享，傳遞互聯網世界有價值的訊息，盡在「技術匯」。