我在思考乙個問題：我們為什麼要搞微服務，整體式服務就不能滿足嗎？為什麼一定要用微服務呢？
服務的粒度拆的約來越細呢？當我們的業務複雜之後，設計乙個系統難度會加大，還要適應快速迭代，就更難了。
將業務的功能拆分之後，會讓每個模組的設計變得簡單。對於需求的變更，採用增加、修改模組的方式來實現也比較方便。
但是，微服務同樣帶來了新的問題。
1、通訊。模組間的資料交流，增加了通訊成本，我們採用rpc的方式來處理模組間的通訊。在選用協議的時候，
要考慮通訊效率，擴充套件性，目前比較常用的是json和protocol buffers
2、命名。模組變多，迭代更新快，這就需要乙個可擴充套件、方便理解的方案來命名、分配識別符號、位址。
3、一致性與副本。為了避免出現訪問瓶頸，對資料物件進行複製是有必要的。這會帶來副本/快取的一致性問題。
這又涉及到如何取捨訪問的粒度。
4、容錯。任何下游連線、節點、程序錯誤的情況下保持操作正確、高效。因此需要具備自穩定性、檢查故障、故障恢復還原的能力。
5、api和透明性。模組和介面太多，除了用介面文件說明以外，最好定義一套通用的風格，比如rest api，方便呼叫方。
6、安全。涉及到使用者隱私的資料，以密文的形式進行傳輸。
微服務拆分
微服務拆分是做微服務架構很重要也很難的話題，很多時候，幾個服務是合還是拆在設計團隊內也很難達成共識。當你糾結應該拆分和合併時我建議就先合併，等後面版本迭代需要時有必要再去做拆分。從系統發展的角度說，很多平台也都是從單體大應用 逐步拆分演化而來的，就像有位大牛說的那樣，一開始就拆分的很好的微服務實踐往...
20190115 微服務拆分原則
微服務拆分 1 對於第乙個問題，是乙個無法度量的問題，粒度多細才是細，多粗才算粗，根本就是你說了算，而且，很多時候，並非夠細或夠粗就是好事情。對於粒度的劃分，李運華老師提出了以專案組開發人員的數量來劃分粒度的想法，我覺得很認同。乙個服務，應該以2 3個人 可以根據團隊成員構成進行分組，以組概念來權衡...
通過Springboot拆分服務構建微服務集
應用背景 1.基於spring boot開發 2.依賴activemq，kafka,redis,mongodb,mysql等開源軟體 3.內部服務伺服器，分布式計算平台服務，檢索服務,訊息推送服務等 拆分原因 1.原有的 應用模組之間高度耦合，各個模組都擔當了牽一髮而動全身的 角色 2.應用的配置資...