微服務學習與思考(01)：什麼是微服務？微服務的優點和劣勢

1、單體應用

在軟件開發早期階段，你們都在一個應用系統上開發。各個業務模塊之間耦合也比較緊密。軟件發佈也是總體發佈，或者對軟件進行打包發佈和部署，好比java能夠打包成war部署。測試也很容易，由於代碼都在一塊兒，基本不須要引用外部的關聯服務。

在軟件開發早期，這種軟件開發模式能適應業務的發展，軟件應用也能夠正常運行。

若是你的業務發展良好，客戶需求會變得愈來愈多，軟件功能數也會隨着客戶的需求變多而變多。爲了實現這些功能，你必須添加不少代碼。而隨着業務進一步發展，代碼量勢必也會越增越多。有可能 2 到 3年後，軟件代碼量會變得很是巨大。那時軟件就會變成一個很是龐大且複雜的單體應用。

此時可能出現的問題：

1. 打包編譯會耗時好久，致使發佈也很耗時。
2. 代碼可維護性變差，由於代碼量大，邏輯複雜，只有少數老員工能所有理解。代碼腐化嚴重。
3. 修改bug和增長新功能會變得困難，可能牽一髮而動全身。
4. 因爲上面的緣由，軟件擴展變得困難
5. 軟件可用性風險增長。可能一個bug致使整個軟件不可用。

爲了解決上面的這些問題，怎麼辦？

2、應用拆分

第一步可能想到的就是拆分應用。
把一個「大泥球 」同樣的單體應用按照業務來進行拆分。好比電商，可能拆分爲商品應用，訂單應用，用戶應用，商鋪應用等等相對比較小的應用。

業務的進一步發展，你可能把上面的應用作進一步拆分，變成更小的應用，以服務的形式對外提供應用。慢慢的變成了比較小的服務-微服務。

隨着軟件架構的調整，能解決上面遇到的問題嗎？大部分能夠解決。
服務穩定的運行了一段時間，你也過了一段舒服的日子。可是在使用微服務的過程當中，問題也逐漸暴露出來，微服務會帶來什麼問題呢？下面對微服務進行一些思考。

3、微服務思考

什麼是微服務

維基百科定義：

微服務 (Microservices) 是一種軟件架構風格，它是以專一於單一責任與功能的小型功能區塊 (Small Building Blocks) 爲基礎，利用模塊化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。

AWS的定義：

微服務是一種開發軟件的架構和組織方法，其中軟件由經過明肯定義的API 進行通訊的小型獨立服務組成。 這些服務由各個小型獨立團隊負責。 微服務架構使應用程序更易於擴展和更快地開發，從而加速創新並縮短新功能的上市時間

微服務有哪些優點與劣勢（問題）

• 優點：

1. 應用小，可快速編譯部署
2. 單個微服務維護性變高，修改容易，由於每一個團隊獨立負責一塊功能。新功能交付變快，能夠快速開發交付
3. 擴展性變高
4. 可靠性變強，能夠部署不少獨立的服務

微服務有這麼多優點，那微服務是「銀彈」嗎？微服務不是銀彈，它帶來了不少優點，同時也帶來了不少劣勢（問題）。

• 劣勢（問題）：

1. 總體複雜度變高，從哪些方面來管理這種複雜度？
2. 運維變得複雜：微服務變多，怎麼監控全部微服務，保證服務穩定？出了問題，怎麼定位問題？
3. 服務管理：微服務變多，管理複雜度變高，治理變得複雜
4. 測試方面的挑戰：你須要結合其餘的微服務來進行集成測試
5. 分佈式問題：分佈式數據一致性、分佈式事務
6. 服務保障：一個服務出了問題，如何才能不影響其餘服務？

根據上面微服務定義，這些服務都是由小型獨立團隊負責，那團隊怎麼劃分？公司組織架構如何調整才能適應微服務的架構發展？這也給組織管理帶來了挑戰。

還有微服務的「微」，多「微」纔是好的「微」？也就是微服務怎麼劃分，如何肯定邊界？
等等這些都是微服務面臨的問題和挑戰。

題外話：任何問題都有正反面，就像一枚硬幣同樣，因此思考問題要多樣化，不能只思考一點。

4、總結

根據以上簡略分析，微服務的實施並非一蹴而就的事情，是隨着業務的發展而發展，是一種逐漸演進的模式。

微服務架構是爲了適應業務的快速變化，產品的快速迭代、交付、反饋和修改，團隊成員膨脹而提出的一種架構解決方案。

微服務的優劣分析能夠看出，微服務並非「銀彈」，它給開發和產品帶來好處的同時，自己也會帶來一系列的問題。如何克服這些問題，纔是實施好微服務的關鍵所在。

上面提到的劣勢（問題），也須要創建運維開發基礎設施來加以保障才能讓微服務順利運行。好比CI/CD，監控體系，配置中心等等，那DevOps是否也要同步建設？

因此成功實施微服務並非一件孤立的事情，它關聯不少其餘事情，架構、工具到團隊協同，須要同步建設，它是一個系統工程。