OFO小黃車微服務架構演進實踐

微服務的核心在於採用「小規模，快反饋」的機制降低軟體系統的複雜性並通過虛擬和自動化技術分散風險，從而可以速食麵對市場變化帶來的各種挑戰，並能夠快速銷售創新，獲得市場的反饋。而不僅僅是利用到了時下新興的語言，編程框架或工具。

需要考慮的問題

單個微服務代碼量小，易修改和維護。但是，系統複雜度的總量是不變的，每個服務代碼少了，但服務的個數肯定就多了。就跟拼圖遊戲一樣，切的越碎，越難拼出整幅圖。一個系統被拆分成零碎的微服務，最後要集成為一個完整的系統，其複雜度肯定比大塊的功能集成要高很多。

單個微服務數據獨立，可獨立部署和運行。雖然微服務本身是可以獨立部署和運行的，但仍然避免不了業務上的你來我往，這就涉及到要對外通信，當微服務的數量達到一定量級的時候，如何提供一個高效的集群通信機製成為一個問題。

單個微服務擁有自己的進程，進程本身就可以動態的啟停，為無縫升級的打好了基礎，但誰來啟動和停止進程，什麼時機，選擇在哪台設備上做這件事情才是無縫升級的關鍵。這個能力並不是微服務本身提供的，而是需要背後強大的版本管理和部署能力。

多個相同的微服務可以做負載均衡，提高性能和可靠性。正是因為相同微服務可以有多個不同實例，讓服務按需動態伸縮成為可能，在高峰期可以啟動更多的相同的微服務實例為更多用戶服務，以此提高響應速度。同時這種機制也提供了高可靠性，在某個微服務故障後，其他相同的微服務可以接替其工作，對外表現為某個設備故障後業務不中斷。同樣的道理，微服務本身是不會去關心系統負載的，那麼什麼時候應該啟動更多的微服務，多個微服務的流量應該如何調度和分發，這背後也有一套複雜的負載監控和均衡的系統在起作用。

微服務可以獨立部署和對外提供服務，微服務的業務上線和下線是動態的，當一個新的微服務上線時，用戶是如何訪問到這種新的服務？這就需要有一個統一的入口，新的服務可以動態的註冊到這個入口上，用戶每次訪問時可以從這個入口拿到系統所有服務的訪問地址。這個統一的系統入口並不是微服務本身的一部分，所以這種能力需要系統單獨提供。

作者:劉連營ofo平台架構部架構師

2017年1月加入ofo,主要負責平台架構基礎服務、中間件等設計研發，主導平台在瘋狂業務增長下多次架構升級,擁有豐富大型互聯網架構實踐經驗，重點關注中間件、微服務、ServiceMesh等領域

【關鍵字回復推薦:微服務 架構設計 微服務架構】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！