SOA通常都是跟ESB結合在一塊兒,會由以下幾個平臺組成html
SmartESB運行平臺web
SmartMonitor監控平臺瀏覽器
SmartGovernance服務治理平臺安全
SmartIDE集成開發平臺服務器
其強調業務系統完全的組件化和服務化。將原有的業務系統分割成若干個獨立應用,而且單獨開發、部署、使用ServiceAPI公開本身的服務微信
如何把握服務分割的粒度。服務粒度越粗,就越難以符合規定原則。服務粒度越細,就越可以靈活地下降變化和負載所帶來的影響。併發
當新增或者修改功能的時候,影響涉及面會變小,只要修改具體某一個服務就能夠了運維
每一個組件都是一個單獨的服務與進程,對於併發,有很好的抗壓性微服務
容易進行功能的拓展組件化
解耦
須要部署多臺服務器,提高了運維工做時間
客戶端調用請求數增多
微服務中不存在ESB企業服務總線,因爲微服務儘可能都是經過HTTP API的方式暴露出去的,所以這種服務管理平臺不須要像傳統企業內部的ESB服務總線這麼重。可是最基本的服務註冊,服務代理,服務發佈,服務簡單的路由,安全訪問和受權,服務調用消息和日誌記錄這些功能仍是須要具有而SOA則存在。即便有了微服務仍是須要一個SOA服務管理平臺來完成
微服務支持使用RPC、AMQP等協議公開服務,可是不是很推薦,其對瀏覽器和防火牆不是很友好,而且最好是內部使用。應用應該在防火牆外採用相似HTTP或者WEBSocket協議
解決客戶端頁面請求數增多的問題
解決若是服務拓展或者合併痛苦問題
API Gateway負責請求轉發、合成和協議轉換。全部來自客戶端的請求都要先通過API Gateway,而後路由這些請求到對應的微服務。API Gateway將常常經過調用多個微服務來處理一個請求以及聚合多個服務的結果。它能夠在web協議與內部使用的非Web友好型協議間進行轉換,如 HTTP協議、WebSocket協議
支持多種格式的請求協議
支持同步、非阻塞I/O
更多技術相關的和話題請關注公衆微信號【APPZone】
私下交流請關注的新浪微博@跡_Jason