微服務概述
SOA團隊 2020-03-16
■ 微服務架構的概念
從上圖可以看到，微服務架構的第一個重點，即業務系統本身的組件化和服務化，原來開發一個業務系統本身雖然分了組件和模塊，但是本質還是緊耦合的，這關鍵的一個判斷標準就是如果要將原有的業務系統按照模塊分開部署到不同的進程里面并完成一個完整業務系統是不可能實現的。而對于微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端web ui，到控制層，邏輯層，數據庫訪問，數據庫都完全是獨立的一套。在這里我們不用組件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。
把這個核心搞清楚后，再來看下網上找到的對微服務架構的一些定義和闡述：
微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制，如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。而在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。
微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，并且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
對于上面紅色字體標注的兩點，再強調下即：
● 首先對于應用本身暴露出來的服務，是和應用一起部署的，即服務本身并不單獨部署，服務本身就是業務組件已有的接口能力發布和暴露出來的。了解到這點我們就看到一個關鍵，即我們在進行單個應用組件設計的時候，本身在組件內部就會有很大接口的設計和定義，那么這些接口我們可以根據和外部其它組件協同的需要將其發布為微服務，而如果不需要對外協同我們完全可以走內部API接口訪問模式提高效率。
● 其次，微服務架構本身來源于互聯網的思路，因此組件對外發布的服務強調了采用HTTP Rest API的方式來進行。這個也可以看到在互聯網開放能力服務平臺基本都采用了Http API的方式進行服務的發布和管理。從這個角度來說，組件朝外部暴露的能力才需要發布為微服務，其本身也是一種封裝后的粗粒度服務。而不是將組件內部的所有業務規則和邏輯，組件本身的底層數據庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。
微服務的基本思想在于考慮圍繞著業務領域組件來創建應用，這些應用可獨立地進行開發、管理和加速。在分散的組件中使用微服務云架構和平臺使部署、管理和服務功能交付變得更加簡單。
■ 微服務架構的核心內容
■ 傳統的單體應用
要講微服務架構，一定涉及到微服務架構和傳統單體應用的區別問題，先看下傳統單體應用：
很多單體應用有時候也在強調是基于組件化和模塊化的開始思路開發的，或者說是基于SOA架構開發，那從運行態和設計態分別來看的話可以看到。
● 從運行態的視角：
1. DB走HA或RAC集群，但是擴展性是大問題，很多應用后期即使走了RAC也無法解決性能問題。
2. 部署的是一個大WAR包，無法分模塊獨立分開部署。
3. WAR部署當前可以是物理機，也可以是虛擬機，但是WAR包偏重，很少直接部署到Docker容器的。
4. Application Server層的性能可以通過負載均衡方式進行水平擴展。
● 從設計態的視角：
1. DB本身是無法拆分的，各個模塊的數據庫，視圖全在一個大的SID或Schema里面。
2. 模塊之間的交互除了通過邏輯層外，還有些是直接通過DB層的跨表連接完成的。
3. 邏輯層的模塊和模塊之間往往是緊耦合的，相互間的調用隨意，很多都是內部API或方法調用。
不管是從運行態還是設計態來看，傳統的單體應用最大的問題就是各個組件和模塊之間緊耦合，而這種耦合帶來的問題就是擴展困難，升級和變更困難（模塊間相互影響大）。
其次，傳統單體應用面臨的第二個問題是展現層和邏輯層的緊耦合，而實際在當前應用架構設計和開發中，可以看到需要同時滿足電腦，平板，手機APP終端等多種前端展現和訪問。而這種訪問必須是支持分布式的接口服務訪問模式。傳統單體應用要做到這點也只有進行改造，比如再單獨增加一個服務代理組件來發布服務。
■ 傳統單體應用到微服務架構
正是由于傳統單體應用存在的一些問題，微服務架構提出了將傳統單體應用打散為多個離散，自治的獨立組件。這些組件你可以稱呼它為微服務模塊，這些微服務模塊本身需要滿足的就是從數據庫，到邏輯層，到界面展現層都能夠是獨立的一套；微服務模塊能夠從需求，設計，開發，測試，部署上線和運維都相對獨立。
這個思想本質仍然是SOA架構思想和組件化思想在業務系統內部應用的體現?；谝陨纤伎?，傳統單體應用轉變為微服務架構后如下圖所示：
● 從運行態的視角：
1. 數據庫在部署的時候是可物理拆分的，即不同微服務模塊的數據庫可以獨立部署。
2. 微服務模塊的應用組件包是獨立部署的。
3. WAR包由于已經按模塊拆分為多個，因此每個WAR包相對來說更加輕，而容易部署到類似Docker容器上。
4. 由于WAR包之間有接口交互和協同，需要增加微服務網關實現服務管理和治理。
● 從設計態的視角：
1. 數據庫，邏輯層和界面展現在設計的時候就是完全相對獨立的一套。
2. 邏輯層的各個組件之間只能通過Service API接口進行交互，微服務架構下推薦輕量Http Rest接口。
3. 邏輯層各個模塊之間徹底實現松耦合，各個模塊本身也更加輕量。
■ 微服務架構的核心單元-微服務網關
在引入微服務架構后，最大的一個變化就是原來單個業務系統內部的各個模塊之間需要通過分布式的服務接口進行調用和協同了，而不是簡單的走內部的API調用。
那么對于復雜的各個模塊間的點對點調用，就需要有一個類似ESB總線的中間件將這些接口服務統一管理起來，以實現對服務注冊，安全，流控，日志審計，消息，代理和路由的統一管理。而這些轉到微服務架構后即是由微服務網關來完成。
在這個意思上來看，微服務網關類似簡化了的ESB，沒有了ESB總線復雜的適配，協議轉換，內容轉換，數據映射，服務編排等功能。也可以說微服務網關是傳統OSGI網關能力的進一步增強。
遠行科技
遠行云商
