微服務概念的出現已經有很多年了，有多少公司在真正使用微服務，今天就把我這幾年對微服務的一點感受和大家分享下：
首先，在系統建立之初，有乙個問題，到底要不要按照微服務的架構來開始專案？
這個時候如果我們是接觸的乙個比較熟悉的行業、熟悉的業務，或者說業務架構師對這一行比較了解，那麼可以考慮進行微服務的設計，如果是這個行業的業務比較新，或者本身技術團隊對這塊業務也在摸索中，那麼建議先簡化系統的設計，快速的把系統開發出來，先成形再改進。
其次，微服務的架構本身存在兩個方面的架構：技術架構和業務架構；技術架構要考慮高可用、高併發2個特點，目前的解決方案基本成熟，包括spring cloud、dubbo等，都提供了一整套的解決方案，下面我會詳細的分享技術方案裡面核心的點，掌握了這些核心的點，那麼乙個微服務技術架構也就沒問題了。另外乙個業務架構，在系統跑了一年以後就是要重點考慮重構優化的事了，在系統建立之初，從我切身感受，考慮業務架構為時過早，這個時候主要考慮如何將業務流程串聯起來，那麼當系統跑了一年以後，如何考慮業務架構呢？
經過一年以上的執行，此時團隊的規模逐漸擴大，專案**也已經很大，團隊由最開始的單個團隊變成了多個團隊。一般情況下，如果公司的業務量沒有上去，那麼這樣的系統也不需要做大的調整，我們這裡考慮的是公司的業務量也隨之發展起來了。由於之前沒有進行專門的業務架構劃分，此時各專案組是針對各個子系統級別進行開發的，各個系統都需要進行某塊業務的開發，這是單體架構最大的問題就是各系統都開發了，都實現了類似而又不同的**邏輯，最麻煩的就是資料庫層，模組之間沒有明確的劃分，前期為了快速上線，資料庫層也沒有經過劃分設計，各個表之間相互關聯，讀寫效率問題尤顯明顯，資料不一致的情況也時有發生。
那麼，問題也找出來了，此時我就要分享下如何去改變這種情況，合適的時候做合適的事，此時做業務架構是最適合的，如果拖延太久，那麼便不那麼好做了，下面我就來分享如何設計，如何抽絲剝繭。
未完待更。。。
微服務實踐 什麼是微服務
微服務是一種軟體架構風格，該詞 於martin fowler 的一篇部落格。他在自己部落格中闡述了微服務六個特點 創業初期 很快完成後，找了家雲服務部署上線，開始了創業之路。規模擴大 這一階段存在著很多不合理的地方 做出改變 在程式設計的世界裡，最重要的是抽象能力，通過整理業務邏輯，抽象初公共的業務...
Abp vNext微服務實踐 服務通訊
服務通訊是微服務架構中必不可少的功能，服務通訊的效率決定了微服務架構的優略。常用的微服務通訊策略有兩種，分別是rpc http，其中rpc以grpc框架為代表使用者最多。abp vnext微服務架構中當然也有服務通訊策略，採用的是http方式進行服務通訊。雖然grpc高效安全，但是相關的.net框架...
微服務實踐 服務運維
監控的基本目標是掌控在生成環境中的服務執行狀況，在系統發生故障後及時報警，並能夠通過監控資訊快速定位問題。監控的另乙個目標是故障預警，在故障發生之前根據設定的規則提前感知並通知維護人員，或者自動做出運維決策。監控所涉及的指標 微服務的監控策略 對於微服務架構的系統，其監控通常由四大模組組成 資料收集...