現在軟件開發很大的問題就是緊跟大企業的腳步，只要大企業採用了什麼技術，很快就會普及下去，開發人員一般不會細細分析自己是不是真的需要這種技術。
這個行為很大程度上是開發人員的自我的技術投資，畢竟開發人員如果有機會採用這些流行技術，也會讓自己在有些場合比較有優勢。
但是這種情況往往浪費人力資源，比如像微服務這種技術，而這種技術並不是非常複雜，而是在於上層設計。
由於獨立性，無狀態，可以隨意佈置和分佈式擴展，所以需要做很多細粒度的拆分，導致開發實施上都會很麻煩，對每個接口的跟蹤監控也更加複雜。
我們看從中間件-SOA-微服務的演進過程中，其實中間件技術已經可以抵禦絕大多數的應用場景，利用中間件的思想去搭建中臺也應該是開發人員默認的思想，需要更多場景可以考慮SOA，微服務說說就好。
我們看到仍舊好多人員採用微服務架構，但是面對所謂的適度的拆分，往往是讓人頭疼。
適度，適什麼度，真麼算是合適，這些都是讓人無法躲避的東西。
首先要確定什麼東西放到微服務環境，什麼東西還是隻是做普通服務調用，不要把一切都扔上微服務，拆分很重要，並不是所有業務都需要用微服務去分割，集中統一我相信仍然是大部分後臺系統唯一正確的集成方式。
首先保持微服務絕大數是技術服務的統一提供接口；其次是非常通用的，甚至是完全可以移植的業務接口，集中大體量的業務訪問量；最後是工具組件部分。
如果是純業務，或者後臺管理平臺，還是完全集成統一更有利於開發，變更，調整。
而微服務保證接口的單一原則，這個也是面向對象開發最終要的原則之一，就是服務所幹的事情是唯一的，不會中間去完成另外一件事。
微服務要在整個環境的語義下，探索接口的定義，如何承接上下文，如何規避業務風險，如何定義統一的接口含義，如何監控等等。
就是說這是說：說話很重要，表達很重要，在統一語義下的表達，可以讓整個環境理解的統一的格式，統一的協議接口。這個需要開發團隊合作共同制定這些規則，形成一致性的調用和維護體質。
保持簡單的模式，儘量保持簡單，形式和語義的簡單方便學習和理解。
微服務是單一功能和無狀態的所以不應該和其他業務發生強耦合，如果是微服務中有依賴就要看看是不是要整合。如果發生如果不拆分兩者都會在應用場景下缺乏表達，這個就要檢查是否是設計的問題了。
每個微服務要有明確的表達，利用組件獲取別的服務，而不是本地服務來相互調用，並且不應該害怕失敗，有完整的錯誤處理環節和記錄。
所以拆分微服務是一個業務和技術重新整理的過程，如何設計才是整個工作的大前提，最好是利用成熟項目，一點點的分析拆分，規劃和合並。
建議微服務是一個小型的生態環境，提供有效，高效的中間層，通過領域模型定義和提煉服務協議和表達的語言。
微服務也是服務，應該讓人隨時監控，數據，內存，服務運行情況等都需要讓運維人員知道，同時有快速替換的方法。回退方法。
雖然上面提供了一些經驗，但是還是不推薦開發去選擇微服務，微服務給運維開發都帶來可一定的開發困難，同時對業務建模提出了非常高的要求，而devops對我們大多數開發團隊來講要求又太高，往往業務開發都會因為在微服務中調試問題而耽擱。
中心化的開發模式，我相信仍然是有生命力的，仍然是一個新項目開始最佳的模式，只有你的量真正發生改變，你才需要逐步轉型。
但是有一點很是要鼓勵，及中臺系統，這是一個很好的提升團隊能力的思路，提升業務的產品化，抽象業務組件，簡化開發都有很好的思路，所以中臺化比只是選擇微服務話要更合理。中臺化需要整個開發團隊的技術信仰和執著。
