什麼是微服務架構
微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的
類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。
概念：把一個大型的單個應用程序和服務拆分爲數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。
定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。
本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。
傳統三層服務架構
三層架構的具體內容如下(MVC)：
- 表示層： 用戶使用應用程序時，看到的、聽見的、輸入的或者交互的部分。
- 業務邏輯層： 根據用戶輸入的信息，進行邏輯計算或者業務處理的部分。
- 數據訪問層： 關注有效地操作原始數據的部分，如將數據存儲到存儲介質（如數據庫、文件系統）及從存儲介質中讀取數據等。
雖然現在程序被分成了三層，但只是邏輯上的分層，並不是物理上的分層。也就是說，對不同層的代碼而言，經過編譯、打包和部署後，所有的代碼最終還是運行在同一個進程中。而這，就是所謂的單塊架構。
業務拆分服務架構
爲什麼會進行業務拆分呢，大多數是因爲，當一個程序的功能越來越臃腫的時候，發佈，迭代，新人接手等問題會日益嚴重，這時候，我們就需要對業務進行拆分重新。
舉個例子：
這是我入職的某家公司的業務架構圖，我們可以很清晰的將不同業務進行理解。
從我的角度來看，後端開發的職責就是合理的將數據進行流動。數據的來源基本都是產生於DB，最後流出於API。
擴展微服務架構
首先要說一些是微服務的特性：
- 單一職責： 微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務通過“管道”的方式靈活組合，從而構建出龐大的系統。（這個點在業務架構拆分的時候基本已經完成）
- 輕量級通信: 服務之間通過輕量級的通信機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的交互方式。(通常在微服務迭代前期，我們都推薦用http協議進行，雖然性能比較低，但是迭代速度會比較快)
- 獨立性: 每個服務在應用交付過程中，獨立地開發、測試和部署。
- 進程隔離: 單塊架構中，整個系統運行在同一個進程中，當應用進行部署時，必須停掉當前正在運行的應用，部署完成後再重啓進程，無法做到獨立部署。在微服務架構中，應用程序由多個服務組成，每個服務都是高度自治的獨立業務實體，可以運行在獨立的進程中，不同的服務能非常容易地部署到不同的主機上。
從特性，我們可以看到其本質：
- 微服務也可以被認爲是一種組件，但是跟傳統組件的區別在於它可以獨立部署，因此它的一個顯著的優勢。另外一個優點是，它在組件與組件之間定義了清晰的、語言無關、平臺無關的規範接口，耦合度低，靈活性非常高。但它的不足之處是，分佈式調用嚴重依賴於網絡的可靠性和穩定性。
- 在單塊架構中，企業一般會根據技能劃分團隊，在這種組織架構下，即便是簡單的需求變更都有可能需要跨團隊協作，溝通成本很高。而在微服務架構中，它提倡以業務爲核心，按照業務能力來組織團隊，團隊中的成員具有多樣性的技能。
- 在單塊架構中，應用基本上是基於“項目模式”構建的，即項目啓動時從不同技能資源池中抽取相關資源組成團隊，項目結束後釋放所有資源。這種情況下團隊成員缺乏主人翁意識和產品成就感。
- 微服務架構中，提倡針對不同的業務特徵選擇合適的技術方案，有針對性的解決具體業務問題，而不是像單塊架構中採用統一的平臺或技術來解決所有問題。
- 微服務架構提供自主管理其相關的業務數據，這樣可以隨着業務的發展提供數據接口集成，而不是以數據庫的方式同其他服務集成。另外，隨着業務的發展，可以方便地選擇更合的工具管理或者遷移業務數據。
同樣爲服務也會有缺點：
性能： 分佈式系統是跨進程、跨網絡的調用，受網絡延遲和帶寬的影響。
可靠性： 由於高度依賴於網絡狀況，任何一次的遠程調用都有可能失敗，隨着服務的增多還會出現更多的潛在故障點。因此，如何提高系統的可靠性、降低因網絡引起的故障率，是系統構建的一大挑戰。
異步： 異步通信大大增加了功能實現的複雜度，並且伴隨着定位難、調試難等問題。
數據一致性： 要保證分佈式系統的數據強一致性，成本是非常高的，需要在 C（一致性）A（可用性）P（分區容錯性） 三者之間做出權衡。
運維成本增高：運維主要包括配置、部署、監控與告警和日誌收集四大方面。微服務架構中，每個服務都需要獨立地配置、部署、監控和收集日誌，成本呈指數級增長。
微服務的問題解決方案
如何訪問
一般使用apigateway方式實現，這個api gateway不一定是一個轉發器，可能只是一個封裝好的sdk代碼。
他的作用包括：
提供統一服務入口，讓微服務對前臺透明
聚合後臺的服務，節省流量，提升性能
提供安全，過濾，流控等API管理功能
如何通信
通信的話，這裏我還是保留我意見，在人力不充足和拆分前期，優先使用http協議。（同樣是封裝在api gateway中，這裏需要進行版本控制）
異步消息調用則用(Kafka, rabiitmq)
我們在考慮同步和異步調用的時候要做一些取捨，通常根據業務類型來，如果要求數據的強一致性，我們一般選用同步調用。相對於同步的話，異步也更加複雜。但是異步系統能更好的面對大流量的衝擊。
如何實現動態感知
動態感知這個通常我們會選用一個開源的高可用的KV組件進行。
如果是GO的話，常用的是ETCD。
在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互感知？服務如何管理？
這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過etcd等類似技術做服務註冊信息的分佈式管理。當服務上線時，服務提供者將自己的服務信息
註冊到etcd（或類似框架），並通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過etcd尋址，根據可定製算法， 找到一個服務，還可以將服務信息緩存在本地以提高性能。
當服務下線時，etcd會發通知給服務客戶端(pub/sub)。
當某個節點崩潰時如何處理
這個其實關注得多，但是應用得少。通常，我們在做服務的時候，會提前考慮到流量峯值的情況，而且微服務的話，水平擴容是很方便的。
但是，肯定會存在這個風險。所以如果沒有特別的保障，結局肯定是噩夢。當我們的系統是由一系列的服務調用鏈組成的時候，我們必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：
- 重試機制（api gateway sdk中應該具有此項功能）
- 限流，有服務提供方提供，ip計數方案，令牌桶方案（限定桶最大值，寫入，訪問方先獲取令牌才能繼續進行，數據結構-棧）。
- 熔斷機制，當訪問一次服務在特定時間內失敗次數達到一定程度，首先發警報，然後停止對此服務的調用。
- 負載均衡，通過流量分配策略（和nginx的upstream異曲同工，但是微服務還可以加上服務健康狀態權重動態分配，這裏就比較複雜了）
- 服務降級，（水平縮減自己的服務，減少DB線程池等）
目前我司迭代的微服務架構如下,並加入了異步數據同步的方式：
總結
沒有完美的架構，要通過不斷迭代處理，找出適合自己業務的架構。
所有脫離業務的架構都是吹牛逼。