服務拆分有以下幾個原則和大家分享
橫向拆分。按照不同的業務域進行拆分，例如訂單、營銷、風控、積分資源等。形成獨立的業務領域微服務集群。
縱向拆分。把乙個業務功能裡的不同模組或者元件進行拆分。例如把公共元件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現業務的服務化拆分。
要做好微服務的分層：梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求
服務拆分是越小越好嗎？微服務的大與小是相對的。比如在初期，我們把交易拆分為乙個微服務，但是隨著業務量的增大，可能乙個交易系統已經慢慢變得很大，並且併發流量也不小，為了支撐更多的交易量，我會把交易系統，拆分為訂單服務、投標服務、轉讓服務等。因此微服務的拆分力度需與具體業務相結合，總的原則是服務內部高內聚，服務之間低耦合。
20190115 微服務拆分原則
微服務拆分 1 對於第乙個問題，是乙個無法度量的問題，粒度多細才是細，多粗才算粗，根本就是你說了算，而且，很多時候，並非夠細或夠粗就是好事情。對於粒度的劃分，李運華老師提出了以專案組開發人員的數量來劃分粒度的想法，我覺得很認同。乙個服務，應該以2 3個人 可以根據團隊成員構成進行分組，以組概念來權衡...
資料庫拆分原則
隨著使用者量的budu不斷提公升，對 應用的併發量也將不斷增高。這將會導致應用卡頓延遲，更嚴重甚至會導致系統整個崩潰。而解決這種情況的發生，下意識便是如何降低使用者對系統資料的讀操作。1 採用redis，memcache等快取技術，降低對資料庫的讀操作。2 其次可以考慮進行資料庫的讀寫分離操作 3 ...
微服務拆分
微服務拆分是做微服務架構很重要也很難的話題，很多時候，幾個服務是合還是拆在設計團隊內也很難達成共識。當你糾結應該拆分和合併時我建議就先合併，等後面版本迭代需要時有必要再去做拆分。從系統發展的角度說，很多平台也都是從單體大應用 逐步拆分演化而來的，就像有位大牛說的那樣，一開始就拆分的很好的微服務實踐往...