微服務是如何製造更多問題的？
如果你聽夠了微服務的好處，並迫不及待的想要著手實施。可能還需要考慮下幾個問題......寫於去年作者的身同感受
- 如何使用微服務製造問題
- 微服務成本
- 理想的微服務平台
聲稱使用微服務架構的公司越來越多，一方面是雲服務商的炒作，另一方面也的確是微服務帶來好處的影響。 無論如何理解，在 twitter 上可以看到越來越多的程序員在吐槽微服務..
一方面，理論上微服務通過大事化小分而治之，可以解決開發周期長，舊項目難以維護等一系列問題，看起來非常萬能。
另一方面很多人忽略了微服務的隱含成本，在實際實施後反而感覺處處不便。
實行微服務所需要的額外工作大致如下幾類：
- 部署困難：需要搭建如 K8s, CloudFoundry 等應用平台來解決
- 測試困難：需要搭建 Jenkins 等 CI 工具來完成單元測試/集成測試
- 運維困難：需要在應用平台上搭建監控和告警服務
- Debug 困難：需要搭建日誌服務接入平台，需要接入調用鏈分析工具
- 代碼維護：微服務化後可能有些服務長期無人修改，對每個服務都需要建立良好的文檔
可以看到，實行微服務需要優秀的運維團隊支撐起應用平台(k8s)、監控告警工具、CI 服務、日誌/調用鏈服務。需要開發團隊做好文檔化、自動化測試。
這些工作在單一應用架構時經常會被忽略掉，但是微服務中如果沒有這些工具 debug、運維 等工作會非常痛苦，會浪費掉團隊大量時間。
所以微服務的先決條件是團隊需要拿出精力來維護以上基礎服務。
很多小團隊選擇使用微服務架構，但後果往往是花費大量額外精力去支撐平台，或在基礎服務不完善的情況下浪費大量時間 debug，實在不是一個好的選擇。而大公司實行微服務帶來的好處則相當明顯，因為人數眾多，維護平台的消耗幾乎可以忽略不計。
有野心的公有雲服務商應該將自身作為所有中小企業的微服務平台，提供微服務架構的所有基礎服務，大量降低使用微服務的成本。這樣微服務才會成為真正通用的架構模式。
從功能上來說 AWS(國外的那個..) 最接近理想形態。已經真正的可以讓中小企業完全基於 AWS 基礎服務來設計自己的後台架構。而其他服務商還多以 VPS + 資料庫的形態出現。
如果以支撐微服務架構為目標的話，AWS 為首的公有雲還都有一定的距離。
不知未來哪一家有野心的廠商可以提供真正實用的微服務公有平台。
推薦閱讀：