一、什么是微服務？

微服務架構定義

微服務的定義源于2014年3月Martin Fowler所寫的一篇文章“Microservices”，微服務的四個特性定義抽象為“小、獨、輕、松”。

微服務的感性認識

轉型之前：

緊耦合組件

慢的部署周期，等待集成測試

轉型之后：

松耦合組件

自動化部署，無需等待獨立組件

微服務優勢

1. 可伸縮性：服務的承載能力在設計之初并不能完全符合后來業務發展的要求，隨著業務量增大，服務要通過服務器集群方式進行擴展，各個微服務的擴展數量也是按需求擴展，承載量大的微服務擴展節點多，承載量小的微服務擴展節點少，從而實現資源有效配置。

2. 降低風險：準備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。

a）從負載均衡列表中移除掉“金絲雀”服務器。

b）升級“金絲雀”應用（排掉原有流量并進行部署）。

c）對應用進行自動化測試。

d）將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。

e）如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）

3. 彈性系統：在理想的設計中，一旦某一非核心微服務啟動失敗，其他微服務仍然可用，用戶在沒有使用到異常模塊所提供的服務時，對這一異常完全無感知，大大增強了用戶體驗。

4. 敏捷：開發成本降低，響應速度加快。各個開發團隊的人員不必耗費大量時間了解整個服務端架構，主要通過了解某個微服務的金融業務需求和技術體系即可參與開發，從而降低了學習成本以及改動代碼帶來的風險，代碼審查流程的簡化也相應地加快了開發響應速度。

5. 靈活：不要求所有的微服務都使用同一種技術和平臺來實現。

微服務架構帶來的問題

1. 依賴服務變更很難跟蹤，其他團隊的服務接口文檔過期怎么辦？依賴的服務沒有準備好，如何驗證我開發的功能。

2. 部分模塊重復構建，跨團隊、跨系統、跨語言會有很多的重復建設。

3. 微服務放大了分布式架構的系列問題，如分布式事務怎么處理？依賴服務不穩定怎么辦？

4. 運維復雜度陡增，如：部署物數量多、監控進程多導致整體運維復雜度提升。

這些解決方案折騰到最后就會明白，原來我們要有一個微服務應用平臺才能整體性的解決這些問題。

微服務架構適用場景

微服務架構并不是萬能的，有它適合采用的系統，這些系統包括：

1. 對于業務流程較為復雜，且業務會逐漸變得更加復雜的系統，單體應用將十分龐大，后期難以修改和維護，應考慮使用微服務架構。

2. 為了滿足業務需求，項目中引入了眾多的技術棧，中間件，單體應用會給開發者帶來很大的困擾，應考慮將應用拆分成多個獨立部署的采用最優技術棧實施的微服務。

3. 高并發的，有高可用和彈性伸縮需求的系統，往往是那些面向龐大數量互聯網用戶的平臺類、交易類系統，應考慮利用微服務架構便于橫向擴展和彈性伸縮的特性。

4. 單體應用版本發布成本高，而單個微服務的變更和發布都很容易，那些有高頻率版本發布需求的系統，應使用微服務架構。

5. 沒有數據實時強一致要求，可接受數據最終一致的系統，可使用微服務架構。

在銀行系統中：

1. OA、HR、績效等管理類系統并不需要微服務架構；

2. 信貸、CRM等管理類應用如果體積龐大（幾十萬行代碼以上），要使用微服務改造；

3. 中間業務、核心賬務、網銀由于系統壓力大，可以采用微服務架構。

微服務架構在互聯網金融方面的應用

1. 第三方支付包括以支付寶、財付通、盛付通為代表的互聯網支付企業，也包括快錢、匯付天下為代表的金融型支付企業。

2. P2P小額信貸是一種個人對個人的直接信貸模式。

3. 大數據金融是指集合海量非結構化數據，通過對其進行實時分析，可以為互聯網金融機構提供客戶全方位信息。

4. 眾籌融資指用團購+預購的形式，向網友募集項目資金的模式。眾籌利用互聯網傳播的特性，讓小企業、藝術家或個人對公眾展示他們的創意，爭取大家的關注和支持，進而獲得所需要的資金援助。

5. 所謂信息化金融機構，是指通過采用信息技術，對傳統運營流程進行改造活重構，實現經營、管理全面電子化的銀行、證券和保險等金融機構。

6. 互聯網金融門戶是指利用互聯網進行金融產品的銷售以及為金融產品銷售提供第三方服務的平臺。它的核心就是“搜索+比價”的模式。