1樓：山間霧
傳統服務是乙個大盒子把需要的功能都放進去，體積比較臃腫，而且這些功能互相沒有太大關聯，需要自己進行拼裝和維護；
微服務是把除基礎功能外的所有功能都放在外面，並且這些功能都形成統一的元件化，開發者可以自定義配置，高效標準規範；在巨集觀方面更好維護和管理，微觀方面輕巧切易於維護。
2樓：「已登出」
微服務是一種科技社會的宗教。
信教的使用者，是最愚蠢的使用者，也是利潤率最高的使用者。商家的利益，就在於把使用者變蠢。
如果乙個行業沒啥技術含量了，那它的出路就是不斷發明新的宗教，讓使用者以為是新的東西，其實是新瓶舊酒。從clien-server，到com，j2ee,soa,iaas,paas。。。總而言之，隔幾年就有一種新的邪教誕生。
3樓：一曦
從無到有構建億級微服務秒殺系統（真實工業界案例）pan.baidu.com/s/1oHiCBU0MEtWIyb1Ut5q6ag
提取碼：6m1p
4樓：杉楓
微服務是將原來一體化架構拆分，微服務是每個模組由單個程式組成，能夠方便迭代，以及機構專業化，資料層只提供資料，個性化只排序，上層組織資料返回給客戶端，微服務能實現橫向以及縱向拆分。並且可以每個模組根據流量進行擴充套件，流量小的可以減少計算資源投入，並且可以根據計算密集型，記憶體消耗性，io型進行不同處理。
電商，Spring Cloud架構，微服務之間耦合過多的問題如何解決？
倚天碼農 你講了了兩個問題。乙個是高度耦合 程式架構和設計 另乙個是http的呼叫效率。這兩個問題的解決方案一般情況下是互相矛盾的。要想解決高度耦合，就需要優雅的設計，但一般效率都不高。要想提高效率，就要使用一些特殊的設計和手段，這必然使程式設計很難看。我們先來看高度耦合 程式架構和設計 模組拆分之...
微服務架構風格可以降低系統的複雜度嗎？
微服務容易分工，容易部署，容易開發，互相耦合鬆散，哪兒哪兒都是好處。但是你碰到坑的人，比方說不寫注釋的，濫用語法糖的，辭職就跑路的人單獨寫乙個微服務。通常再找乙個人接的時候接手的會選擇重寫 Tech觀世界 微服務架構下,單個應用簡單,整體複雜。單個應用簡單意味著開發人員可以快速迭代 快速修復bug ...
「微服務」架構設計中如何把握「微」度，需要考慮哪幾方面因素？
kimmking 實際上服務劃分的本質是對系統進行架構設計，服務的劃分粒度沒有絕對的過大或過小之說，不同階段的側重點和思考的角度也不盡相同。創業初期的團隊，過分的追求微服務，為了 微 而微，反而會導致業務邏輯過於分散，技術架構過於複雜，團隊基礎設施搭建能力弱，進而導致忽略了快速迭代交付產品的重要性，...