在過去的幾天,我一直在咀嚼着關於微服務的相關概念,惟恐給本身落下一絲的不明白,也算是給本身採起的掃盲行動。畢竟也是在微服務圈子裏混的人了,不把概念吃透,還怎麼出去跟人家撕x呢?html
講真,身邊結識的大牛也沒幾個,也沒有什麼高逼格的朋友圈,都是本身一路摸爬滾打過來的,想一想幾年前的本身,真替本身感到心酸。編程
近來常有文章提到「微服務」尚未一個相對官方的定義。segmentfault
在我看來,就好像是「未婚先孕」。架構
在尚未準備好的時候,忽然就橫空出世了,並且還至關轟轟烈烈。app
所以,我就尋思:我是否是該看看一些相對官方一點的文獻材料呢?到底有沒有定義?微服務究竟是以一種什麼形態存在着?運維
不用懷疑,《Microservices》當屬最原汁原味的官方文獻材料了。編程語言
《Microservices》應該算是我讀過最短的論文了,整個過程(不含擴展閱讀內容),大約花了我1.5個小時,算是理解了其中心思想了。微服務
若是中間不開小差的話,1個小時讀完差很少了。測試
這是我解開的第一個困惑:關於微服務,確實沒有官方正式的定義。ui
不只如此,關於微服務的架構指導思想,或者說是最佳實踐,也並無出爐。
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.
概括起來,有如下五點:
咱們姑且認爲這就是微服務的定義吧!畢竟「微服務」的獨創是《Microservices》這篇論文的做者,而且也獲得了業界普遍的承認。
這篇論文除了「microservice」,另外還有一個高頻詞彙:「monolith」。
「monolith」能夠理解成是傳統開發模式下的「單體應用」,在《我所瞭解的微服務》一文中有說起到,而且將其與微服務的模式作過簡單的對比。
在《Microservices》這篇論文中也不例外地將單體應用和微服務兩種開發模式作了比較詳細的對比。
結果呢?
固然不能讓monolith輸的這麼難堪呀!畢竟仍是有不少公司採用這種開發模式的。
通篇讀下來,發現做者屢次在強調單體應用的一個「軟肋」:
small change requires the entire monolith to be rebuilt and deployed.
一次小變動,就意味着整個應用要從新打包,部署。對於其餘沒有變動的業務模塊,將會受到不小的影響。而微服務的優越性在於獨立打包,獨立部署,將服務之間的影響降到最低。
此外,文中就兩種開發模式的團隊管理進行了討論。
單體應用隨着應用規模的不斷擴大,團隊規模也隨之擴張,將團隊劃分紅不一樣的業務線就是一個技術活,團隊成員之間的溝通協做也是一個巨大的挑戰,更不用說在這個團隊裏必須遵照統一的規約了。
微服務的高度自治的特性使得上述問題變得不那麼棘手了。各個服務之間的聯繫是鬆散的,能夠用不一樣的編程語言實現,僅靠特定的協議相互調用。關於單個服務的規模大小,一篇擴展閱讀有提到過:《How big is a microservice?》
結論是:一我的,最多十幾我的,最後仍是不肯定,大概就是要咱們視狀況而定吧!
不過,正是由於微服務的通訊方式(lightweight mechanisms, often an HTTP resource API),致使了一部分的不肯定性,也是應用出錯的場景之一。由於服務之間的調用並不像單體應用那樣的本地方法調用,因此可能有各類因素致使各個服務之間溝通不順暢。
文中說起了到了微服務的一個特性:
Products not Projects
「作產品,而不是作項目」,這實際上是一種開發理念的轉變。大多數應用的開發都以軟件交付爲目的,開發完成後就交給運維部門管理了,項目團隊也隨之解散了。而做者在文中強調,微服務的開發模式可不能這樣。整個團隊應該跟隨着應用的全生命週期,開發者與微服務之間創建一種微妙的鏈接。亞馬遜有一個著名的理念:
You build, you run it.
然後文的 Infrastructure Automation 一小節則提到了可持續集成與可持續交付,開發者經過自動化測試,自動化部署完成以後的工做。附上一張經典的pipeline示意圖:
再後來的 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、容器化都是不可迴避的話題。
對於微服務的將來展望,做者仍是說得很謙虛含蓄的。
做者也並無強調從此的設計理念應該要使用微服務,而是應該根據實際的業務需求,模塊劃分邊界以及團隊自身的技術水平等因素來制定。仍是這句話:
但不管如何,微服務的架構風格值得每一個公司認真去思考。畢竟相對於單體應用,微服務的架構仍是利大於弊的。
據我目前的實踐經驗來看,實施這套理念仍是須要有一支精幹的技術團隊,每個人都具有必定的開發經驗,否則的話,是很難開展工做的。若是一旦決定採用微服務架構風格了,必然要以「小步快跑,迭代試錯」的節奏進入實施。
敏捷開發?我想是吧!
但願對你有所幫助。
THANKS!
每日干貨分享,傳遞互聯網世界有價值的訊息,盡在「技術匯」。