低調的牛肉
我認為沒有最好的服務架構，只有最適合的服務架構。微服務好不好要根據公司的業務來判斷。很多互聯網大公司在做中臺化改造是因為業務發展的需要，當業務體量上來之後倒逼公司服務架構和組織架構調整。
微服務的優勢顯而易見，主要有幾個特點：無中心化，松耦合，服務自治，組件化。這樣的結構便於將複雜的系統結構拆分，各個服務團隊更加靈活，能夠提高交付速度，快速響應市場變化。
然而不能為了微服務而微服務，公司在架構選型的時候首先要評估業務體量與複雜度是否有微服務化的必要，如果業務本身不復雜，那麼完全沒必要去微服務化。否則不僅不能提高業務運行效率，反而為增加開發運維的負擔。
微服務的缺點如下：
首先服務的切分需要慎重考慮，微服務化是手段不是目的，最終目的是通過有效的拆分應用，實現敏捷開發和部署，提高交付速度，擁抱變化。
其次微服務應用是典型的分佈式系統，需要更加關注服務的可用性和一致性問題。服務註冊與發現，容錯，降級，熔斷，限流等服務治理問題在微服務場景下可能要複雜的多。
第三微服務帶來了運維的複雜性。一次完整的業務調用可能需要多個服務協同完成，服務的調用關係更加複雜，可能是串行/並行，可能同步/異步。如果沒有強大的工具鏈的支撐，運維會是一場噩夢。
最後微服務不僅是技術架構的調整也是組織架構的調整。伴隨著業務系統微服務化的同時，組織架構也應該打破傳統的筒倉效應，更加扁平和靈活。
攻城獅Bilbo
還是以公司的實際情況來選擇技術架構吧，不要為了微服務而微服務。
微服務的特徵
微服務是一種軟件架構設計思想，它以【單一責任】的功能模塊為基礎，再利用模組化的方式組合出複雜的大型應用程序；微服務的主要特徵有這些：
每個微服務的業務功能會盡可能的單一（只關注負責的業務）；
可以獨立部署；
輕量級的通信協議；
每個微服務擁有單獨的數據持久化（有些項目的微服務改造，數據庫依然是一個數據庫）；
不僅服務微，團隊也要“微”；
微服務帶來的好處
每個微服務可以獨立擴展，因為服務微，所以單個服務可以快速擴展；
因為彼此沒有依賴關係，所以可以獨立升級（需要使用到灰度發佈）；
-
故障和資源隔離，出現事故只會影響單個或幾個微服務（當然如果是關鍵服務發生問題，影響面也會比較大）；
只要約定好通信協議，每個微服務可以採用不同的技術棧；
如果採用微服務的架構來管理團隊，團隊將不再以職責劃分（開發團隊、需求團隊、測試團隊、運維團隊），每個微服務團隊都包含各個方面的人員，合作起來會更加“敏捷”。
微服務的缺點和它的優點一樣明顯
說是缺點，也可以說是挑戰：
極大地增加了運維的複雜程度，包括上線發佈、BUG排查、故障解決等；如果沒有良好的自動化運維平臺和工具，上微服務要謹慎（人肉運維會死人的）；
數據一致性不好控制；如果是單體服務，幾張表的讀寫通過事務很容易控制，但是在微服務的架構中，數據一致性是一個很大的難題；
增加了集成測試的難度；
需要一個統籌全局的角色，否則很容易做很多重複性的開發；
微服務間的調用會有延遲（通信成本），網絡延遲可能帶來整體系統的響應緩慢問題；
總之，微服務不僅僅是技術方面的問題，它涉及的方方面面還有很多，還是要選擇適合公司的架構。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
微服務之前的架構——單體架構
在微服務沒有盛行的時候，所有的企業都是基於單體架構。也就是JAVA的一個WAR包，GoLang的單一可執行文件，Ruby或
Node.js
的一個目錄和它之下的子目錄中包含的各種源碼。單體架構存在多種好處，包括：
1. 開發簡單
2. 易於更改
3. 測試相對簡單直觀
4. 部署簡單
5. 橫向擴展簡單
...
但是，隨著時間的推移，開發、測試、部署和擴展都會變得非常困難。
隨著公司的發展，研發團隊規模不斷狀大，代碼庫規模變大。曾經小巧、簡單的，由一個團隊開發維護的項目，經過多年成長，演變成一個由大團隊開發的巨無霸單體架構應用程序。
如下圖所示
單一源代碼倉庫導致額外的溝通和協調成本，從代碼得交到生產環境部署需要經歷很多周折，變更必須等待手工測試。 應用變得龐大、複雜、不可靠、難以維護。
也就是說，當單體架構變得過度龐大和複雜，以至於任何一個開發者都很難理解它的全部，修復軟件中的問題和正確地實現新功能將變得困難且耗時，而且非常容易出問題。
解決單體架構問題-微服務（忽略SOA等過程發展....）
如圖，微服務的概括定義是：把應用功能性分解為一組服務的架構風格。每一個服務都是由一組專注的、內聚的功能職責組成。
所以，微服務可以有這些好處
1. 大型複雜應用程序可以持續交付和持續部署
2. 每個服務相對較小並容易維護
3. 服務可以獨立部署
4. 服務可以獨立擴展
5. 可以實現團隊的自治
6. 更好的容錯性等
...
但是，微服務同樣也來帶了弊端。
1. 服務的拆分和定義是一項挑戰
2. 分佈式系統帶來的各種複雜性，使開發、測試和部署變得困難
3. 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊
...
內容小結
所以，微服務是一把好處和弊端共存的雙刃劍，採用微服務架構是一個需要認真思考的決策。
在使用微服務架構時，一些問題無法迴避，必須得到解決。每個問題都可能存在多種解決辦法，同時伴隨著各種權衡和取捨，並沒有一種完美的解決方案。
在開發中使用單體架構還是直接使用微服務架構，需要根據具體的情況來判斷。
一切的脫離場景說架構，都是而流氓。
java架構筆記
簡介
系統架構中，微服務是很流行的，尤其是現在我們的系統的數據越來越大，越來越複雜，為了設計更合理，支持高可用、高性能，最好的實踐方式就是進行微服務化。其中的優點就不多說了。單就從缺點層面來分析。
缺點
技術要求變高
對於開發人員的技術要求越來越高，隨著服務的微服務化。一個系統的微服務應該怎麼拆，拆的維度是什麼？這個是沒有一定的標準可言，而是要根據項目本身的業務而定，這就需要一個有經驗的架構師進行微服務化。而是簡單的進行垂直拆分即可。
除此之外你還需要考慮如何避免多個微服務之間開發人員的重複開發工作，做到公共資源的合理分配。微服務中的監控指標數據等。
這樣的拆分對於之後的系統升級、擴展是不是合理，會不會導致系統架構重組等問題，都是其中的一個弊端。
運維成本
隨著你的微服務化，會導致服務數量的激增，你需要去維護更多的服務，以及服務之間的性能監控，數據調用鏈等數據指標。而傳統的單體方式，本身的調用都是內部的，你只需要維護單個應用即可。
注意，這個也並非是指分佈式，而是你的系統微服務化，所以傳統單體應用也可以做到高可用。
複雜度高
微服務之間的調用方式是通過RPC方式來進行數據交互，相比傳統模式，你需要考慮過載、消息丟失、重試、負載等場景，需要處理的邏輯也很多。
首先你需要有一個註冊中心，來幫助微服務之間的調用，這是一個需要額外實現的點。
另外在服務調用（服務發現）的時候，會存在負載均衡、容錯、代理透明、RPC協議中的序列化、協議編解碼等比較複雜的詳細邏輯，都是需要微服務化需要去考慮的。
分佈式鎖、分佈式事務層面的問題，你都需要再進行設計，在傳統的模式下，這些都是在同一個應用裡面進行，不存在問題。但是微服務化後，你為了保證數據一致性，這些相關的點，都是你需要進行額外的開發。難度成本也會成倍加高。
性能層面
隨著你需要為了微服務化，而加入更多的解決方案的時候，你的系統會變得更加的複雜，雖然架構清晰，設計合理。但是其中的性能問題，也是你不得不考慮的問題，越多的中間件組合在一起，只要其中一個環節出現問題。你整體的性能就會大打折扣，比如你微服務RPC環節、通信延遲、微服務宕機等情況。不像傳統模式，環節少。
總結
微服務化的優點很多，但是同時帶來的問題也是客觀存在的開發要求高、複雜性、性能等。
針對以上的一些拙見，個人的建議是對於你是否引入微服務化，應當考慮維度在於業務邏輯和系統邊界是否清晰。可以先從最簡單的傳統單機模式開發，漸漸穩定系統後可以再慢慢的微服務化的拆分工作。
油膩的Java
題主做軟件的應該聽說過“沒有銀彈”這句話吧？如果真有一個能解決所有問題的軟件，還要這麼多軟件開發人員幹嘛？如果有人說有，不是沒幹過軟件，就是在打廣告。
“微服務”不是銀彈，解決不了所有問題，有其自己的適應場景。我大致總結了如下場景：
- 業務發展較快，希望能在後期快速的支撐爆發增長的訪問量（首先確認是不是真的業務發展很快）
- 業務非常複雜，且有很多不確定性，可以考慮領域驅動設計+微服務實現
- 項目很大，人員很多，考慮切分為多個小組進行微服務開發
- 需要整合很多的老系統，可以考慮微服務的sidecar模式或者SOA
- 希望在公司層面構建一套統一的業務技術平臺。登陸，文件服務，日終服務等，由業務平臺提供，開發人員只需要關注業務服務
相對的，需要快速落地的簡單業務就不適合微服務，後期維護成本遠超成本。
就像，大型超市有多個收銀臺，小超市也搞多個收銀臺，營業額還不夠發人員工資的。
最後，技術是為業務服務的，一個技術在某個場景的優勢，在另一個場景下可能就變成了劣勢，拋開業務討論哪個技術好不好，都是耍流氓～
架構思維
微服務架構主要針對日流量千萬以上，研發團隊規模不少於50人的公司，如果小於這個規模我建議認真評估是否真的需要採用微服務架構。
— 這是我見過的最良心的話，BAT等大廠出來的技術，不斷禍害創業界。很有必要在這裡嚴正指出微服務的使用範圍，也就是規模匹配度，很多技術leader丟掉【規模】這個重要參數搭建不適合業務的架構。
想當年，當年毛澤東品讀《戰爭論》，深思到以少勝多的戰役，只是鳳毛麟角，於是拋棄其他奇技淫巧，集中優勢兵力，殲滅有生力量。
作為創業的你， 日訂單十萬就足夠對嗎？ 那就不要考慮微服務架構了。
太早了，等融資到D輪都不遲！
創業者田甜
微服務適用於擁有 500 多名工程師的公司。它們通過創建強大的所有權邊界，強大的產品定義，鬆散的耦合來幫助團隊管理複雜的相互依賴性，並允許團隊以自己的速度和部署節奏進行工作。如果您要與 20 個人一起進行微服務，那您做錯了。
程序君
微服務主要是經過組件分離各自擁有獨立的生命週期，並且按需進行擴展，這種方式打破了組件之間的技術依賴，這就允許每個服務各自選擇最合適的技術進行實現，即不同的服務甚至可以採用不同的編程語言來實現，一定程度上微服務使技術方案變得更加靈活。
微服務在使用過程中開發、測試、部署等環節十分便捷，整體是以松耦合高內聚的形式存在，符合IT技術思想。但是在實際使用過程中，還是存在一些不足，比如在開發微服務時，對於服務粒度的設計需要對業務理解比較深刻；客戶端調用微服務耗時比較嚴重，隨著需求的迭代，管理難度越來越大，服務間耦合度開始增強，代碼難以複用和修改等等。
綜上所述，對於複雜的大型的項目來說，採用微服務實現就會變得十分複雜且週期也會很長。在這種情況下，通常建議採用SOA架構幫助企業制定正確的IT架構戰略（具體包括應用架構、數據架構、技術架構），通過微服務輔助實現應用架構，是一個不錯的選擇。
數通暢聯
首先環節多了，系統架構複雜了，管理和維護難度加大了。
其次，微服務之間的調用相對於內部方法調用更加複雜，需要考慮更多的異常處理機制。
第三，微服務的拆分粒度大小一直都是困擾架構小組的問題，不僅僅是大小問題，還要考慮業務劃分合理性及應用調用便捷可靠性的問題。
第四，隨著系統規模的增長，微服務也會不斷增多，系統複雜度增長，故障定位會較為困難。相應的，如果要恢復出錯交易，可能需要涉及多個系統的協同和聯動，處理時間增加。
第五，多小組之間的協同開發也是個難題，溝通成本增加。
死鬼麻煩
2014年用微服務解決了單體應用的問題；2016年用docker解決了微服務的問題；2018年用k8s解決了docker的問題…… 哪有銀彈？只是見招拆招。
