低調的牛肉
還是以公司的實際情況來選擇技術架構吧，不要為了微服務而微服務。
微服務的特徵
微服務是一種軟件架構設計思想，它以【單一責任】的功能模塊為基礎，再利用模組化的方式組合出複雜的大型應用程序；微服務的主要特徵有這些：
每個微服務的業務功能會盡可能的單一（只關注負責的業務）；
可以獨立部署；
輕量級的通信協議；
每個微服務擁有單獨的數據持久化（有些項目的微服務改造，數據庫依然是一個數據庫）；
不僅服務微，團隊也要“微”；
微服務帶來的好處
每個微服務可以獨立擴展，因為服務微，所以單個服務可以快速擴展；
因為彼此沒有依賴關係，所以可以獨立升級（需要使用到灰度發佈）；
故障和資源隔離，出現事故只會影響單個或幾個微服務（當然如果是關鍵服務發生問題，影響面也會比較大）；
只要約定好通信協議，每個微服務可以採用不同的技術棧；
如果採用微服務的架構來管理團隊，團隊將不再以職責劃分（開發團隊、需求團隊、測試團隊、運維團隊），每個微服務團隊都包含各個方面的人員，合作起來會更加“敏捷”。
微服務的缺點和它的優點一樣明顯
說是缺點，也可以說是挑戰：
極大地增加了運維的複雜程度，包括上線發佈、BUG排查、故障解決等；如果沒有良好的自動化運維平臺和工具，上微服務要謹慎（人肉運維會死人的）；
數據一致性不好控制；如果是單體服務，幾張表的讀寫通過事務很容易控制，但是在微服務的架構中，數據一致性是一個很大的難題；
增加了集成測試的難度；
需要一個統籌全局的角色，否則很容易做很多重複性的開發；
微服務間的調用會有延遲（通信成本），網絡延遲可能帶來整體系統的響應緩慢問題；
總之，微服務不僅僅是技術方面的問題，它涉及的方方面面還有很多，還是要選擇適合公司的架構。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
題主做軟件的應該聽說過“沒有銀彈”這句話吧？如果真有一個能解決所有問題的軟件，還要這麼多軟件開發人員幹嘛？如果有人說有，不是沒幹過軟件，就是在打廣告。
“微服務”不是銀彈，解決不了所有問題，有其自己的適應場景。我大致總結了如下場景：
- 業務發展較快，希望能在後期快速的支撐爆發增長的訪問量（首先確認是不是真的業務發展很快）
- 業務非常複雜，且有很多不確定性，可以考慮領域驅動設計+微服務實現
- 項目很大，人員很多，考慮切分為多個小組進行微服務開發
- 需要整合很多的老系統，可以考慮微服務的sidecar模式或者SOA
- 希望在公司層面構建一套統一的業務技術平臺。登陸，文件服務，日終服務等，由業務平臺提供，開發人員只需要關注業務服務
相對的，需要快速落地的簡單業務就不適合微服務，後期維護成本遠超成本。
就像，大型超市有多個收銀臺，小超市也搞多個收銀臺，營業額還不夠發人員工資的。
最後，技術是為業務服務的，一個技術在某個場景的優勢，在另一個場景下可能就變成了劣勢，拋開業務討論哪個技術好不好，都是耍流氓～
架構思維
簡介
系統架構中，微服務是很流行的，尤其是現在我們的系統的數據越來越大，越來越複雜，為了設計更合理，支持高可用、高性能，最好的實踐方式就是進行微服務化。其中的優點就不多說了。單就從缺點層面來分析。
缺點
技術要求變高
對於開發人員的技術要求越來越高，隨著服務的微服務化。一個系統的微服務應該怎麼拆，拆的維度是什麼？這個是沒有一定的標準可言，而是要根據項目本身的業務而定，這就需要一個有經驗的架構師進行微服務化。而是簡單的進行垂直拆分即可。
除此之外你還需要考慮如何避免多個微服務之間開發人員的重複開發工作，做到公共資源的合理分配。微服務中的監控指標數據等。
這樣的拆分對於之後的系統升級、擴展是不是合理，會不會導致系統架構重組等問題，都是其中的一個弊端。
運維成本
隨著你的微服務化，會導致服務數量的激增，你需要去維護更多的服務，以及服務之間的性能監控，數據調用鏈等數據指標。而傳統的單體方式，本身的調用都是內部的，你只需要維護單個應用即可。
注意，這個也並非是指分佈式，而是你的系統微服務化，所以傳統單體應用也可以做到高可用。
複雜度高
微服務之間的調用方式是通過RPC方式來進行數據交互，相比傳統模式，你需要考慮過載、消息丟失、重試、負載等場景，需要處理的邏輯也很多。
首先你需要有一個註冊中心，來幫助微服務之間的調用，這是一個需要額外實現的點。
另外在服務調用（服務發現）的時候，會存在負載均衡、容錯、代理透明、RPC協議中的序列化、協議編解碼等比較複雜的詳細邏輯，都是需要微服務化需要去考慮的。
分佈式鎖、分佈式事務層面的問題，你都需要再進行設計，在傳統的模式下，這些都是在同一個應用裡面進行，不存在問題。但是微服務化後，你為了保證數據一致性，這些相關的點，都是你需要進行額外的開發。難度成本也會成倍加高。
性能層面
隨著你需要為了微服務化，而加入更多的解決方案的時候，你的系統會變得更加的複雜，雖然架構清晰，設計合理。但是其中的性能問題，也是你不得不考慮的問題，越多的中間件組合在一起，只要其中一個環節出現問題。你整體的性能就會大打折扣，比如你微服務RPC環節、通信延遲、微服務宕機等情況。不像傳統模式，環節少。
總結
微服務化的優點很多，但是同時帶來的問題也是客觀存在的開發要求高、複雜性、性能等。
針對以上的一些拙見，個人的建議是對於你是否引入微服務化，應當考慮維度在於業務邏輯和系統邊界是否清晰。可以先從最簡單的傳統單機模式開發，漸漸穩定系統後可以再慢慢的微服務化的拆分工作。
