一、單體應用
在軟體開發早期階段，大家都在一個應用系統上開發。各個業務模組之間耦合也比較緊密。軟體釋出也是整體釋出，或者對軟體進行打包釋出和部署，比如java可以打包成war部署。測試也很容易，因為程式碼都在一起，基本不需要引用外部的關聯服務。
在軟體開發早期，這種軟體開發模式能適應業務的發展，軟體應用也可以正常執行。
如果你的業務發展良好，客戶需求會變得越來越多，軟體功能數也會隨著客戶的需求變多而變多。為了實現這些功能，你必須新增很多程式碼。而隨著業務進一步發展，程式碼量勢必也會越增越多。有可能 2 到 3年後，軟體程式碼量會變得非常巨大。那時軟體就會變成一個非常龐大且複雜的單體應用。
此時可能出現的問題：
- 打包編譯會耗時很久，導致釋出也很耗時。
- 程式碼可維護性變差，因為程式碼量大，邏輯複雜，只有少數老員工能全部理解。程式碼腐化嚴重。
- 修改bug和增加新功能會變得困難，可能牽一髮而動全身。
- 由於上面的原因，軟體擴充套件變得困難
- 軟體可用性風險增加。可能一個bug導致整個軟體不可用。
為了解決上面的這些問題，怎麼辦？
二、應用拆分
第一步可能想到的就是拆分應用。
把一個“大泥球 ”一樣的單體應用按照業務來進行拆分。比如電商，可能拆分為商品應用，訂單應用，使用者應用，商鋪應用等等相對比較小的應用。
業務的進一步發展，你可能把上面的應用做進一步拆分，變成更小的應用，以服務的形式對外提供應用。慢慢的變成了比較小的服務-微服務。
隨著軟體架構的調整，能解決上面遇到的問題嗎？大部分可以解決。
服務穩定的執行了一段時間，你也過了一段舒服的日子。但是在使用微服務的過程中，問題也逐漸暴露出來，微服務會帶來什麼問題呢？下面對微服務進行一些思考。
三、微服務思考
什麼是微服務
維基百科定義：
微服務 (Microservices) 是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。
AWS的定義：
微服務是一種開發軟體的架構和組織方法，其中軟體由通過明確定義的API 進行通訊的小型獨立服務組成。 這些服務由各個小型獨立團隊負責。 微服務架構使應用程式更易於擴充套件和更快地開發，從而加速創新並縮短新功能的上市時間
微服務有哪些優勢與劣勢（問題）
- 優勢：
- 應用小，可快速編譯部署
- 單個微服務維護性變高，修改容易，因為每個團隊獨立負責一塊功能。新功能交付變快，可以快速開發交付
- 擴充套件性變高
- 可靠性變強，可以部署很多獨立的服務
微服務有這麼多優勢，那微服務是“銀彈”嗎？微服務不是銀彈，它帶來了很多優勢，同時也帶來了很多劣勢（問題）。
- 劣勢（問題）：
- 整體複雜度變高，從哪些方面來管理這種複雜度？
- 運維變得複雜：微服務變多，怎麼監控所有微服務，保證服務穩定？出了問題，怎麼定位問題？
- 服務管理：微服務變多，管理複雜度變高，治理變得複雜
- 測試方面的挑戰：你需要結合其他的微服務來進行整合測試
- 分散式問題：分散式資料一致性、分散式事務
- 服務保障：一個服務出了問題，如何才能不影響其他服務？
根據上面微服務定義，這些服務都是由小型獨立團隊負責，那團隊怎麼劃分？公司組織架構如何調整才能適應微服務的架構發展？這也給組織管理帶來了挑戰。
還有微服務的“微”，多“微”才是好的“微”？也就是微服務怎麼劃分，如何確定邊界？
等等這些都是微服務面臨的問題和挑戰。
題外話：任何問題都有正反面，就像一枚硬幣一樣，所以思考問題要多樣化，不能只思考一點。
四、總結
根據以上簡略分析，微服務的實施並不是一蹴而就的事情，是隨著業務的發展而發展，是一種逐漸演進的模式。
微服務架構是為了適應業務的快速變化，產品的快速迭代、交付、反饋和修改，團隊成員膨脹而提出的一種架構解決方案。
微服務的優劣分析可以看出，微服務並不是“銀彈”，它給開發和產品帶來好處的同時，本身也會帶來一系列的問題。如何克服這些問題，才是實施好微服務的關鍵所在。
上面提到的劣勢（問題），也需要建立運維開發基礎設施來加以保障才能讓微服務順利執行。比如CI/CD，監控體系，配置中心等等，那DevOps是否也要同步建設？
所以成功實施微服務並不是一件孤立的事情，它關聯很多其他事情，架構、工具到團隊協同，需要同步建設，它是一個系統工程。