低調的牛肉
大家好，我是一名科技領域的創作者，很高興為大家回答這個問題，讓我給大家解決一下！下面我說一下我的個人觀點，希望可以幫助到大家，同時也希望得到大家的認可！
微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
首先來說下有點：
第一、每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求
第二、微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的
第三、微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值
再來說下缺點：
第一、微服務架構可能帶來過多的操作
第二、分佈式系統可能複雜難以管理
第三、.當服務數量增加，管理複雜性增加
希望以上為大家分享這一個問題對大家有所幫助，我希望我的分享關於這個問題能夠幫助到大家，也同時也希望大家能夠喜歡我的分享。
歡迎你們來互相討論
深度微觀察
還是以公司的實際情況來選擇技術架構吧，不要為了微服務而微服務。
微服務的特徵
微服務是一種軟件架構設計思想，它以【單一責任】的功能模塊為基礎，再利用模組化的方式組合出複雜的大型應用程序；微服務的主要特徵有這些：
每個微服務的業務功能會盡可能的單一（只關注負責的業務）；
可以獨立部署；
輕量級的通信協議；
每個微服務擁有單獨的數據持久化（有些項目的微服務改造，數據庫依然是一個數據庫）；
不僅服務微，團隊也要“微”；
微服務帶來的好處
每個微服務可以獨立擴展，因為服務微，所以單個服務可以快速擴展；
因為彼此沒有依賴關係，所以可以獨立升級（需要使用到灰度發佈）；
故障和資源隔離，出現事故只會影響單個或幾個微服務（當然如果是關鍵服務發生問題，影響面也會比較大）；
只要約定好通信協議，每個微服務可以採用不同的技術棧；
如果採用微服務的架構來管理團隊，團隊將不再以職責劃分（開發團隊、需求團隊、測試團隊、運維團隊），每個微服務團隊都包含各個方面的人員，合作起來會更加“敏捷”。
微服務的缺點和它的優點一樣明顯
說是缺點，也可以說是挑戰：
極大地增加了運維的複雜程度，包括上線發佈、BUG排查、故障解決等；如果沒有良好的自動化運維平臺和工具，上微服務要謹慎（人肉運維會死人的）；
數據一致性不好控制；如果是單體服務，幾張表的讀寫通過事務很容易控制，但是在微服務的架構中，數據一致性是一個很大的難題；
增加了集成測試的難度；
需要一個統籌全局的角色，否則很容易做很多重複性的開發；
微服務間的調用會有延遲（通信成本），網絡延遲可能帶來整體系統的響應緩慢問題；
總之，微服務不僅僅是技術方面的問題，它涉及的方方面面還有很多，還是要選擇適合公司的架構。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
微服務之前的架構——單體架構
在微服務沒有盛行的時候，所有的企業都是基於單體架構。也就是JAVA的一個WAR包，GoLang的單一可執行文件，Ruby或
Node.js
的一個目錄和它之下的子目錄中包含的各種源碼。單體架構存在多種好處，包括：
1. 開發簡單
2. 易於更改
3. 測試相對簡單直觀
4. 部署簡單
5. 橫向擴展簡單
...
但是，隨著時間的推移，開發、測試、部署和擴展都會變得非常困難。
隨著公司的發展，研發團隊規模不斷狀大，代碼庫規模變大。曾經小巧、簡單的，由一個團隊開發維護的項目，經過多年成長，演變成一個由大團隊開發的巨無霸單體架構應用程序。
如下圖所示
單一源代碼倉庫導致額外的溝通和協調成本，從代碼得交到生產環境部署需要經歷很多周折，變更必須等待手工測試。 應用變得龐大、複雜、不可靠、難以維護。
也就是說，當單體架構變得過度龐大和複雜，以至於任何一個開發者都很難理解它的全部，修復軟件中的問題和正確地實現新功能將變得困難且耗時，而且非常容易出問題。
解決單體架構問題-微服務（忽略SOA等過程發展....）
如圖，微服務的概括定義是：把應用功能性分解為一組服務的架構風格。每一個服務都是由一組專注的、內聚的功能職責組成。
所以，微服務可以有這些好處
1. 大型複雜應用程序可以持續交付和持續部署
2. 每個服務相對較小並容易維護
3. 服務可以獨立部署
4. 服務可以獨立擴展
5. 可以實現團隊的自治
6. 更好的容錯性等
...
但是，微服務同樣也來帶了弊端。
1. 服務的拆分和定義是一項挑戰
2. 分佈式系統帶來的各種複雜性，使開發、測試和部署變得困難
3. 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊
...
內容小結
所以，微服務是一把好處和弊端共存的雙刃劍，採用微服務架構是一個需要認真思考的決策。
在使用微服務架構時，一些問題無法迴避，必須得到解決。每個問題都可能存在多種解決辦法，同時伴隨著各種權衡和取捨，並沒有一種完美的解決方案。
在開發中使用單體架構還是直接使用微服務架構，需要根據具體的情況來判斷。
一切的脫離場景說架構，都是而流氓。
java架構筆記
我認為沒有最好的服務架構，只有最適合的服務架構。微服務好不好要根據公司的業務來判斷。很多互聯網大公司在做中臺化改造是因為業務發展的需要，當業務體量上來之後倒逼公司服務架構和組織架構調整。
微服務的優勢顯而易見，主要有幾個特點：無中心化，松耦合，服務自治，組件化。這樣的結構便於將複雜的系統結構拆分，各個服務團隊更加靈活，能夠提高交付速度，快速響應市場變化。
然而不能為了微服務而微服務，公司在架構選型的時候首先要評估業務體量與複雜度是否有微服務化的必要，如果業務本身不復雜，那麼完全沒必要去微服務化。否則不僅不能提高業務運行效率，反而為增加開發運維的負擔。
微服務的缺點如下：
首先服務的切分需要慎重考慮，微服務化是手段不是目的，最終目的是通過有效的拆分應用，實現敏捷開發和部署，提高交付速度，擁抱變化。
其次微服務應用是典型的分佈式系統，需要更加關注服務的可用性和一致性問題。服務註冊與發現，容錯，降級，熔斷，限流等服務治理問題在微服務場景下可能要複雜的多。
第三微服務帶來了運維的複雜性。一次完整的業務調用可能需要多個服務協同完成，服務的調用關係更加複雜，可能是串行/並行，可能同步/異步。如果沒有強大的工具鏈的支撐，運維會是一場噩夢。
最後微服務不僅是技術架構的調整也是組織架構的調整。伴隨著業務系統微服務化的同時，組織架構也應該打破傳統的筒倉效應，更加扁平和靈活。
攻城獅Bilbo
在“微服務”這幾個字被明確地提出來之前，其實已經有很多it開發團隊在實施自己的類似概念了。針對客戶不同的業務需要，從設計階段就開始有意地拆分各項業務功能，使它們之間儘可能地降低耦合度，做到最大程度上的獨立；並且在具備足夠條件的情況下，將每一個獨立服務做單獨部署。
這麼做的好處顯而易見，在設計及開發階段，獨立服務模塊就可以交給獨立團隊去開發，做到整個系統開發時間能夠大幅縮短；在實施階段，無論哪個服務模塊需要升級或調整，只要遵循早期設計的接口規範，都能對其它服務做到最低程度的影響，而不是說因為需要調整某一項小功能而導致整個生產系統全面停止工作。
但微服務帶來的問題也是很顯著的，那就是各項獨立服務之間要怎麼通信，換言之就是如何做到數據傳遞的有效性和及時性。所以伴隨著“微服務”概念的大規模提出，浮現出了大量的數據通信和交互、消息隊列、身份認證同步等等非業務產品和解決方案。並且微服務架構對開發團隊的綜合項目管理能力也會有一定的要求，否則繁雜的接口設計和溝通會拖垮整個開發過程。
所以說，使用微服務到底好不好，到底要不要使用，還是取決於具體的業務需要。切忌盲目跟風，為了微服務而微服務，很多時候反而會得不償失。
斯人若月
簡介
系統架構中，微服務是很流行的，尤其是現在我們的系統的數據越來越大，越來越複雜，為了設計更合理，支持高可用、高性能，最好的實踐方式就是進行微服務化。其中的優點就不多說了。單就從缺點層面來分析。
缺點
技術要求變高
對於開發人員的技術要求越來越高，隨著服務的微服務化。一個系統的微服務應該怎麼拆，拆的維度是什麼？這個是沒有一定的標準可言，而是要根據項目本身的業務而定，這就需要一個有經驗的架構師進行微服務化。而是簡單的進行垂直拆分即可。
除此之外你還需要考慮如何避免多個微服務之間開發人員的重複開發工作，做到公共資源的合理分配。微服務中的監控指標數據等。
這樣的拆分對於之後的系統升級、擴展是不是合理，會不會導致系統架構重組等問題，都是其中的一個弊端。
運維成本
隨著你的微服務化，會導致服務數量的激增，你需要去維護更多的服務，以及服務之間的性能監控，數據調用鏈等數據指標。而傳統的單體方式，本身的調用都是內部的，你只需要維護單個應用即可。
注意，這個也並非是指分佈式，而是你的系統微服務化，所以傳統單體應用也可以做到高可用。
複雜度高
微服務之間的調用方式是通過RPC方式來進行數據交互，相比傳統模式，你需要考慮過載、消息丟失、重試、負載等場景，需要處理的邏輯也很多。
首先你需要有一個註冊中心，來幫助微服務之間的調用，這是一個需要額外實現的點。
另外在服務調用（服務發現）的時候，會存在負載均衡、容錯、代理透明、RPC協議中的序列化、協議編解碼等比較複雜的詳細邏輯，都是需要微服務化需要去考慮的。
分佈式鎖、分佈式事務層面的問題，你都需要再進行設計，在傳統的模式下，這些都是在同一個應用裡面進行，不存在問題。但是微服務化後，你為了保證數據一致性，這些相關的點，都是你需要進行額外的開發。難度成本也會成倍加高。
性能層面
隨著你需要為了微服務化，而加入更多的解決方案的時候，你的系統會變得更加的複雜，雖然架構清晰，設計合理。但是其中的性能問題，也是你不得不考慮的問題，越多的中間件組合在一起，只要其中一個環節出現問題。你整體的性能就會大打折扣，比如你微服務RPC環節、通信延遲、微服務宕機等情況。不像傳統模式，環節少。
總結
微服務化的優點很多，但是同時帶來的問題也是客觀存在的開發要求高、複雜性、性能等。
針對以上的一些拙見，個人的建議是對於你是否引入微服務化，應當考慮維度在於業務邏輯和系統邊界是否清晰。可以先從最簡單的傳統單機模式開發，漸漸穩定系統後可以再慢慢的微服務化的拆分工作。
油膩的Java
——什麼是微服務：微服務(Microservices Architecture)，它是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
優點：每一個服務足夠內聚，足夠的小，所以代碼容易理解，這樣能夠聚焦一個指定的業務功能或業務需求。它開發簡單，開發效率也提高，一個服務可能就是專一的只幹一件事情。微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的，微服務能夠被小團隊單獨開發， 也能使用不同的語言開發。
微服務易於第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins、Hudson等。微服務容易被一個開發人員理解、修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值，它允許你利用融合最新技術， 只是業務邏輯的代碼，不會和HTML/CSS或其他界面組件混合，每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以統一數據庫。
缺點：微服務將原來的函數式調用改為服務調用，不管是用rpc，還是http、rest方式，都是增大系統整體延遲。這個是再所難免的了，就需要我們將原來的串行編程改為併發編程甚至異步編程，所以增加了技術門檻。
微服務應用程序是一個分佈式系統，這帶來了複雜性，開發人員需要選擇並實現基於消息傳遞或RPC的進程間通信機制。此外呢，還必須編寫代碼來處理部分故障，因為請求的目的地可能很慢或不可用。
TM野指針
微服務的初衷大概是因為服務化成本太高，想做低成本的服務化，乃名微服務。但病診對了，藥沒開對，多數吃藥的反而病情加重了，吃藥後因為服務化帶來的繁瑣和低效更甚以前。總之，病是真病，藥是錯藥。這一點和中臺倒很像。
微服務的藥方，大多是拆分邪路，restful邪路，獨立佈署邪路。這些都是增加成本，降低效率的。
以拆分為例批一下（這破概念毛病太多，懶得一一批了）
一個業務的複雜度不會因為拆分而減少。相反還會增加額外的技術成本，協作成本。整體複雜度是升高而不是降低的。開發效率是降低而不是升高的。
正確的做法是
1，瞭解拆分是業務複雜度到一定程度下，難以控制的分治之法。複雜性無法治理是前提。
簡單業務用分佈式微服務框架，無疑是火車拉芝麻。效率低下，成本高昂。
2，知道分治這種方法存在的問題，會增加合成成本。警惕拆分，理智分治。分治之法為不得已法。
正確的做法是一隻眼看拆分，一隻眼看合成。拆分以分治領域複雜度，合成兼顧學習，使用，運維低成本。
大多數人只看前者，忽視後者。這就導致大多數微服務的深入實踐效果並不好。這根本上是由於微服務本身的哲學思想分治的必然結果，而大多數人難以體會掌控其中的微妙之處。很難使用的好。
但是類似springboot、springcloud等經過倖存者偏差而存在微服務框架的確是好的。
初學者使用微服務，原業務不動，基礎設施換為微服務框架，最初一定會得益於大量基礎設施，感覺東西好。
但是，如果不深入擁抱，只是淺嘗輒止，只是將框架換為微服務，在微服務原教旨主義者看來不過是換了一件衣服。是假的微服務，是可鄙的，low的。而初學者也難以自視，多數會追求進步。而一旦深入，開始拆分業務。一定會越來越差。
這其中奧妙是第二隻眼兼顧合成的要求實在是太高，兼顧合成本質是要預料未知（的業務情況）做應對，使得業務發生的時候極具針對性，使用簡單底層本。這前提是大量知識和經驗前提這本身已經足夠pass掉大多數人了；並且內置業務變化適配也是違反內聚耦合的；其中設計還要掌握尺寸，既不過度設計，還要簡單好用；玄之又玄，其難度遠超普通開發甚至大多數所謂架構師的水平。很難掌控的住微妙。微服務確實是很好，卻不具備方法的一般性。普通的公司、個人極少見到用的好的。
所以，大多數的微服務實踐，一定是越深入越爛。所謂拆分一時爽，合併火葬場。霸王槍不是人人都hold的住的。
中臺的病，不是服務低效病，而是中國式的業務驅動式開發帶來的低效病，最終產生了焦油坑。本質是《人月神話》所描述的軟件工程面臨的深層次的痼疾。雖然是馬雲第一個看病，但是效者雲集，一時洛陽醫貴，人人皆以病為榮，以中臺為榮。
雖然不少楚王細腰，但其實也是星星之火，非一日之寒。萬企熱熱鬧鬧做中臺，大部分還都是有病的。人月神話的病，焦油坑的病，誰沒有呢？病必定在，不過輕重緩急而已。只要軟件在變，業務在變，就有病。不過是變得頻率快慢，決定了病的急徐。這是軟件內在的規律決定的。
中臺病雖然開了一堆的藥方，但仔細看看，卻發現什麼字都沒有。另外很多數據中臺，技術中臺，XX中臺，看起來不像藥方，倒像蹭飯。
要說和微服務的不同，可能是藥方都沒開的出來，各種江湖偏方、野郎中紛紛上陣，萬眾中臺，人人試藥。不過至今沒見到有效果的。不過吃掛了的倒不多見。這倒是不開藥方的好處了，好歹亂吃的時候，還是有點辨別的；若大師開了藥方，便是雖然直覺不妙，但是捏著鼻子也要硬吃下去的。
中臺病難治啊。 阿里最初定了個15一18的三年中臺戰略，不過一直到19年都沒宣佈成功。19年行癲宣佈阿里不做saas只做被集成。這意味著阿里在業務市場上的瘋狂擴張進入了停滯期，業務中臺戰略碰到了極大困難。19年末業務中臺大將玄難離職。星環隕落。
但，阿里中臺不成功，未必別人不成功。沒有證據證明阿里現在的技術就是最完美無瑕的，不能再做進化的。也沒有證據證明中臺阿里做不成別人必然做不成。但可以知道的是我們現在的技術和現況距離完美無瑕還差的很遠。並且人月深化雖然號稱沒有銀彈，卻也沒有確切的邏輯和證據能證明這一點。
IT技術管理那些事兒
題主做軟件的應該聽說過“沒有銀彈”這句話吧？如果真有一個能解決所有問題的軟件，還要這麼多軟件開發人員幹嘛？如果有人說有，不是沒幹過軟件，就是在打廣告。
“微服務”不是銀彈，解決不了所有問題，有其自己的適應場景。我大致總結了如下場景：
- 業務發展較快，希望能在後期快速的支撐爆發增長的訪問量（首先確認是不是真的業務發展很快）
- 業務非常複雜，且有很多不確定性，可以考慮領域驅動設計+微服務實現
- 項目很大，人員很多，考慮切分為多個小組進行微服務開發
- 需要整合很多的老系統，可以考慮微服務的sidecar模式或者SOA
- 希望在公司層面構建一套統一的業務技術平臺。登陸，文件服務，日終服務等，由業務平臺提供，開發人員只需要關注業務服務
相對的，需要快速落地的簡單業務就不適合微服務，後期維護成本遠超成本。
就像，大型超市有多個收銀臺，小超市也搞多個收銀臺，營業額還不夠發人員工資的。
最後，技術是為業務服務的，一個技術在某個場景的優勢，在另一個場景下可能就變成了劣勢，拋開業務討論哪個技術好不好，都是耍流氓～
架構思維
微服務架構主要針對日流量千萬以上，研發團隊規模不少於50人的公司，如果小於這個規模我建議認真評估是否真的需要採用微服務架構。
— 這是我見過的最良心的話，BAT等大廠出來的技術，不斷禍害創業界。很有必要在這裡嚴正指出微服務的使用範圍，也就是規模匹配度，很多技術leader丟掉【規模】這個重要參數搭建不適合業務的架構。
想當年，當年毛澤東品讀《戰爭論》，深思到以少勝多的戰役，只是鳳毛麟角，於是拋棄其他奇技淫巧，集中優勢兵力，殲滅有生力量。
作為創業的你， 日訂單十萬就足夠對嗎？ 那就不要考慮微服務架構了。
太早了，等融資到D輪都不遲！
