微服務的出現，仿佛秋天里的第一杯奶茶，給了互聯網企業初戀的感覺，仿佛所有的問題都迎刃而解了。整個企業都在推進微服務的改革。
“某個技術難題攻克不了，大概是系統架構問題吧？老板，我們轉型微服務吧”
“老板，我們這個新項目要開始了，現在都流行微服務架構，我們直接采用微服務架構設計吧”
“老板，現在云計算這么火，大家都在轉型做微服務，我們也技術升級做微服務吧“
架構師們仿佛抓住救命稻草一樣，不管三七二十一，轟轟烈烈的就開干了，遇到問題再說。遇到問題再說，那就晚了，對于架構師來說，頂多就是再換個老板，但對于企業來說，很有可能就是沒了。微服務真挺好的，但是在你決定做之前，請做充足的調研，確認自己是否真的適合？
從微服務的定義來看，是把應用拆分成一個個的原子服務，服務與服務之間通過調用進行通信，每個團隊維護一個服務，單獨開發，單獨上線，把之前業務之間的測試互相依賴、上線互相依賴的關系進行了改善。從研發需求開發上線及整體的流程來看，服務拆分成了微服務之后，每個微服務對應于一個代碼倉庫，按服務和倉庫維度進行開發與上線，從一開始維護成本就很高。
當一個新人加入團隊后，以前的單體式應用很方便于新人學習，只要在代碼倉庫將服務下載下來，本地啟程序跑起來就好，模塊與模塊之間的調用不用管，在本地的代碼編輯器很快就能了解到代碼的業務邏輯。而當服務拆分成微服務之后，對于新人來說，學習成本是非常高的，需要有團隊成員講解這個服務的架構、微服務架構，再一個個的下載下來，解決服務與服務之間的調用問題，才能將服務運行起來，看代碼時也是跨多個倉庫查看，很麻煩。除此之外，根據統計數據，單體項目的每行代碼平均成本是比較低的，隨著項目發展和業務復雜度變高，代碼開發和維護成本才會變高，而微服務的開發和維護成本一開始就比較高，隨著業務和項目變得復雜，代碼的開發和維護成本才逐漸降低。因此在技術改革時，需要根據當前項目的重要程度、可用資源等，來權衡找到最合適的架構方式。
在微服務架構中最理想的模式是每個服務都可以單獨運行起來，有自己的業務邏輯、數據庫、中間件、機器資源，當業務邏輯改變時，對應功能的開發和部署成本很低。在一個電商系統中，我們拆分成了用戶管理、訂單管理、庫存管理、支付管理等微服務模塊，當業務擴大后，我們需要再增加一個優惠券管理模塊，增加的時候就比較方便，直接開發此模塊的功能，在微服務網關中增加路由即可。
但隨之帶來的問題是如何管理微服務拆分帶來的多個微服務項目，你可能需要最底層的硬件資源都是容器，便于彈性伸縮，再到開發、測試、發布、運維時需要全自動化的系統，開發上線時使用持續集成交付系統按服務按需求的快速發布上線，運維時通過全面的監控系統把握全局，出問題時快速找到解決方案。這些基礎能力的建設與維護成本也是很高的。因此在技術改革時，需要考慮自己的業務是否需要快速迭代？自己的底層能力建設如何？不要本末倒置。
消息使用微服務技術架構必用分布式部署架構，分布式架構將單機部署的業務拆分成多個機器部署，可根據業務情況無限的彈性伸縮，實現高性能、高可用、高并發。
但是使用分布式也存在很多問題，比如數據一致性問題。提供業務的服務不可能讓不同的用戶訪問到的數據不是同一版本，這樣整體就都亂了，因此使用了分布式模式之后，跨服務的操作需要分布式事務保障操作的原子性、當多人對同一個服務操作時需要分布式鎖保證該操作的原子性。這些都是使用分布式架構帶來的額外成本，我們享受了它所帶來的福利，也必定要為其付出代價。因此在技術改革時，需要考慮自己的每個業務都需要高性能嗎？對于分布式所帶來的成本能承擔嗎？不要因小失大。
服務沒有拆分微服務之前，模塊與模塊的通信是內部調用實現的，沒有什么網絡延遲。但是當服務拆分成了微服務之后，模塊就變成了微服務，微服務與微服務之間的網絡通信就是外部調用實現，服務通信之間因為網絡傳輸會存在延遲，而且如果網絡通信出了問題，那么服務的整體服務質量就會變低。因此在技術改革時，非技術成本之類問題也需要考慮。
微服務是真的好，諸如阿里、京東、美團、滴滴等互聯網巨頭，都將自己的業務體系升級為微服務架構，全公司上線都是微服務體系，但是在整體改革中也付出了很大的成本，加上整體業務規模巨大、研發資源充足，才享受了微服務所帶來的好處。我們可以學習借鑒大廠們的經驗，但在實際開始去做之前，一定要結合自己本身業務情況、資源情況，再來衡量自己是否真的適合～
