以前的文章討論過《網際網路架構，究竟為啥要做服務化？》，隨著資料量、併發量、業務複雜度的增長，網際網路架構會出現以下問題：
「服務化」是乙個很好的解決上述痛點的方案。
那麼問題來了，微服務架構多「微」才合適？
行業內有這樣四類常見實踐。
這是最粗獷的玩法，所有基礎資料，都通過乙個統一的服務來進行訪問。
在業務不是特別複雜的時候，這不失為乙個快速分層的方案，一旦業務變得複雜，服務層會變得非常重，成為耦合焦點。
則只有乙個統一的服務層，使用者資訊，好友資訊，群組資訊，訊息資訊都通過這個服務層來訪問。
如果所有的資料訪問都通過乙個服務層來訪問，那麼一行**出故障，就將影響整個服務，所以更合理的做法是在服務層進行拆分。
服務層架構如何細分？
這樣的話，乙個服務出問題也不會影響其他服務，與此同時，資料層也按照業務垂直拆分開了。
服務粒度變細之後，出現乙個新的問題，業務與服務的連線關係變複雜了，有什麼好的優化方案麼？
資料訪問服務最初是從dao/orm的資料訪問需求過來的，所以有些公司也有乙個資料庫乙個服務的玩法。
乙個子業務對應乙個服務的玩法如下圖：
拆分成乙個資料庫乙個服務，則架構會變成下面的樣子：
群資訊庫，群成員庫，群訊息庫之間也解耦開，不會相互影響。
微服務架構中，更極端的，甚至乙個介面對應乙個微服務。
這樣的話，架構就從：
進化為：
多個服務操縱同乙個資料庫，任何介面服務出問題，都不會影響其他介面服務。使用這種方案的，一般與開發語言特性結合比較緊密，例如golang。
上文中談到的服務化與微服務，不同粒度的服務化各有什麼優劣呢？
總的來說，細粒度拆分的優點有：
細粒度拆分的不足也很明顯：
互聯公司，以「子業務」作為微服務粒度是最常用，訂單服務，使用者服務，支付服務等等。
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
微服務架構
一 先了解一下什麼是單體應用 就是乙個應用程式包含了所有模組功能，各模組同時部署。當然這種應用模式比較容易部署 測試，但隨著專案的加大，單體模式就會變得越來越臃腫，維護的成本逐漸變高。當乙個模組出錯，整個應用都會出現問題，擴充套件能力也會受到限制。二 什麼是微服務 是將整個應用程式分解為多個模組，各...
微服務架構
簡單來說，微服務架構風格想要開發一種由多個小服務組成的應用，每個服務執行於獨立的程序，並且採用輕量級互動，多數情況下乙個http的資源api，這些服務具備獨立業務能力並可以通過自動化部署方式獨立部署，這種風格使最小化集中管理，從而可以使用多種不同的程式語言喝資料儲存技術 james lewis 和 ...