背景
隨著科技的發展使用網路的人越來越多，自身業務發展越來越快，多，高。單體系統會過於臃腫，複雜，很難擴充套件，效能隨之越來越差，效率越來越低。
1 目標
讓每個單獨的功能或者獨立的業務做成單獨的服務，這樣的優點增加系統可擴充套件性，實現應用之間的解藕。
2 優缺點
1 優點
解決單體服務複雜，臃腫，擴充套件性差，實現高耦合低內聚的系統特點。
開發難度降低，開發效率變高，開發成本變低。
2 缺點
進入微服務之後 ， 解決了集中式架構的單體應用很多問題， 但是新的問題應運而生 ， 微服務的粒度應該多大 ？微服務如何設計呢？微服務如何拆分 ？微服務邊界在** ？有人認為
微服務很簡單，就是將之前的單體應用拆分成多個部署包， 或者將原來的單體應用架構替換為一套支援微服務的技術架構，就算是微服務了。還有人認為微服務應該拆分得越小越好。導致
很多專案因為前期拆分過度， 導致複雜度過高， 導致後期難以運維甚至難以上線。或者上線後很難再改動。
1微服務的問題點
微服務最大的問題點就是邊界很難劃分。微服務拆分困境產生的根本原因就是不知道業務或者微服務的邊界到底在什麼地方。換句話說，確定了業務邊界和應用邊界，這個困境也就迎刃而解了。
2 解決問題的方式
劃分邊界是個很複雜的是，我的建議是根據業務場景，系統目前狀態，包括架構狀態和應用狀態來，具體劃分。舉個例子例如登入和註冊這兩個功能，本質上都是對使用者賬戶資訊的操作，如果系統並不複雜可以放在乙個應用中，但是如果系統過於複雜，例如註冊關聯外部第三方的資訊傳送，還有一些非使用者本人資訊建立例如家庭資訊，登入亦是如此，這時候就要考慮是否拆分成兩個功能。
此外目前正在興起被大家接受的ddd模式也是解決問題的辦法，ddd的思路進行業務梳理可以很好規劃服務邊界。
2 優缺點
abp vNext微服務框架分析
本文 自 abp vnext新框架的熱度一直都很高，於是最近上手將vnext的微服務demo做了一番研究。我的體驗是，vnext的微服務架構確實比較成熟，但是十分難以上手，對於沒有微服務開發經驗的.net人員來說幾乎是看不懂的，所以研究一番後再這裡做一些簡單的分析便於新手能夠快速理解並使用。難點 在...
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務 關於微服務的思考
通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...