架構是演進的，不是一蹴而就。
“架構演進趨勢圖”中的趨勢分析，在業界比較公認。這個圖本身的內容、關於各個架構的描述、優缺點等等，網上簡單搜尋一下有大把大把的，感興趣的同學可以自行搜尋，畢竟這也不是我們文章的重點。
軟體發展的不同時期、階段，對技術的理解、選擇和應用都有著不一樣的訴求。架構的選型，永遠只有“合適與不合適”，永遠沒有“哪個更好”的說法。我們今天來談論微服務，並不是因為它更牛，而是經過謹慎分析，認為微服務的思想更符合我們的目標。 什麼是「微服務架構」？
既然聊的是“為什麼”，那麼首先要明白“什麼是”。 「一解釋就懂，一問就不知，一討論就打架」，這是之前我在網上看到的一句話，笑了好久，太貼切了，就搬了過來。
提到微服務，就沒法不提到這位“大神”——馬丁·福勒，他沒有直接給微服務下一個精準的定義，而是給出了微服務特點的描述，大概從以下四個方面來說：
1.根據業務模組劃分服務種類
2.每個服務可以獨立部署並且互相隔離
3.通過輕量的API呼叫服務
4.服務需要保證良好的高可用性
第一點，按業務拆分服務，這是“水平拆分”；在技術層面的“前後分離”，屬於“垂直拆分”；橫縱一起切，就把單一的應用拆分成網狀的小塊應用，這是微服務中「微」思想的體現。
第二點，獨立部署與互相隔離，這點充分體現了“我為人人、人人為我”的設計理念，這是微服務中「服務」思想的體現。
第三點，關於輕量API，微服務本身是推薦使用輕量的通訊協議和簡單的資料結構，實際上，實施環節通常採用的都是http+json的方式。這樣做的好處是，服務之間不再需要關心對方的模型，僅通過事先約定好的介面來進行資料流轉即可。這是微服務中「解耦」思想的體現。
最後一點，比較通用了，就是現如今各種設計都必須考慮的事情。
於是，我給微服務下了一個定義（如圖）。
在實際工作中，我們遇到過各式各樣的問題，有些是技術問題，有些是業務問題，還有些是管理問題，這裡拿其中一個案例來說一下。
這種事情說大不大，說小不小。其中最麻煩的事情是“推諉”的發生。每個獨立組織都有自己的考核指標和關注點，而實際情況又不可能把具體的一個任務的界限劃分得特別清晰。例如介面定義，哪怕說的是“雙方坐下來一起商討決定”，最終還是會有一方對此事負責，推諉在所難免。
微服務的指導思想其中一塊就是關於組織機構調整的，這還有個專門的定律叫“康威定律”，感興趣的可以自行搜尋瞭解。
我們的解決辦法也很有效果。在組織機構沒有完全按照微服務的理念重新規劃之前，這類需要跨組織協同完成的任務，直接成立臨時專案組：相關的部門出人的出人、出資源的出資源，指定／選拔一個能hold住的專案經理對整件事情負責，然後大家驚奇的發現：“部門牆”問題不見了，因為所有事情都是組內事情了，整體的完成情況跟全部專案組成員的業績都掛鉤了，事情推進就非常順利。在順利交付之後，專案組解散，各回各家。極大的提升了溝通效率、交付速度，同時使得資源利用率也得到了很大的提升。
其實很多時候，大家解決問題的想法和思路，並不是要有了微服務才這樣做，而是“不謀而合”，微服務就存在於我們日常工作的點點滴滴之中。
有的。通過我們不斷的摸索和總結，要做好微服務，就要做好一定的準備工作，從四個具體的方面來談：
業務拆分 – 體現在設計環節：在設計的時候，要有足夠的判斷力來合理的規劃服務之間的界限。 服務治理 – 底層技術的支援：首先要選一款適合自己實際情況的分散式服務基礎框架，對於服務的發現、治理、熔斷、降級，都要做好相應的技術準備。
自動測試：一定要自動化。微服務一個明顯的表象就是隨著服務的增多，如果繼續沿用傳統的測試模式就會遇到瓶頸，為了保證高效的迭代，儘量做到更多的環節實現自動化。
自動運維 ：微服務拆分之後，每個服務都可以獨立部署，進而言之應該是隨時隨地可以升級。尤其當網際網路發展到今天，業務要保持對市場變化的一個高效響應，自動化運維就是提升交付速度的一個重要環節。
最後一定要提的是「監控」：包括硬體環境、服務狀態、系統健康度、介面呼叫情況、異常的實時告警以及潛在問題的事先預警等等。「監控」在實施微服務過程中會重要到什麼程度呢？一句話：沒準備好監控，就不要搞微服務。
最後，微服務不是銀彈，軟體領域沒有銀彈，微服務以其特有的優勢在解決一些問題的同時，也引入了其他問題，這幾點，必須要深刻的思考。
「三思而後行」。
——————————————————分割線——————————————————
我是黑少，直男一枚，微服務硬核玩家，喜歡分享、愛交友人、崇尚“實踐出真知”的理念，以折騰鼓搗程式碼為樂
我的微信：weiweiweiblack （備註：掘金 ）
微信公號：黑少微服務，專注微服務技術分享，非技術不八卦！