item 科大 傳遞 服務區 消息傳遞 太多的 醫療 mage 什麽

SOA

面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。 SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之後的自然延伸。 SOA將能夠幫助軟件工程師們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。 微服務

微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個服務器上。微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麽它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那麽它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

相對於單體架構和SOA，它的主要特點是組件化、松耦合、自治、去中心化，體現在以下幾個方面：

• 一組小的服務
  服務粒度要小，而每個服務是針對一個單一職責的業務能力的封裝，專註做好一件事情。

• 獨立部署運行和擴展
  每個服務能夠獨立被部署並運行在一個進程內。這種運行和部署方式能夠賦予系統靈活的代碼組織方式和發布節奏，使得快速交付和應對變化成為可能。

• 獨立開發和演化
  技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術可以獨立演化。服務與服務之間采取與語言無關的API進行集成。相對單體架構，微服務架構是更面向業務創新的一種架構模式。

• 獨立團隊和自治
  團隊對服務的整個生命周期負責，工作在獨立的上下文中，自己決策自己治理，而不需要統一的指揮中心。團隊和團隊之間通過松散的社區部落進行銜接。

我們可以看到整個微服務的思想就如我們現在面對信息爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個復雜的系統和組織能夠快速的應對變化。

一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful（"狀態傳輸" 或 "狀態轉移 "）和RPC的比較也是一個很有意 思的話題。一般REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調用，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個 的開發規範和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。而異步消息的方式在分布式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續幹自己該幹的活，不至於被後臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據最終一致性；還有就是後臺服務一般要 實現冪等性，因為消息發送出於性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分布式管理

也是一個很大的挑戰。

微服務優點

• 每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
• 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
• 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
• 微服務能使用不同的語言開發。
• 微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, bamboo 。
• 一個團隊的新成員能夠更快投入生產。
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關註自己的工作成果。無需通過合作才能體現價值。
• 微服務允許你利用融合最新技術。
• 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
• 微服務能夠即時被要求擴展。
• 微服務能部署中低端配置的服務器上。
• 易於和第三方集成。
• 每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。

微服務架構的缺點

• 微服務架構可能帶來過多的操作。
• 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能雙倍的努力。
• 分布式系統可能復雜難以管理。
• 因為分布部署跟蹤問題難。
• 當服務數量增加，管理復雜性增加。

SOA與微服務區別

相同點

• 需要Registry，實現動態的服務註冊發現機制；
• 需要考慮分布式下面的事務一致性，CAP原則下，兩段式提交不能保證性能，事務補償機制需要考慮；
• 同步調用還是異步消息傳遞，如何保證消息可靠性？SOA由ESB來集成所有的消息；
• 都需要統一的Gateway來匯聚、編排接口，實現統一認證機制，對外提供APP使用的RESTful接口；
• 同樣的要關註如何再分布式下定位系統問題，如何做日誌跟蹤，就像我們電信領域做了十幾年的信令跟蹤的功能；

差別

• 是持續集成、持續部署？對於CI、CD（持續集成、持續部署），這本身和敏捷、DevOps是交織在一起的，我認為這更傾向於軟件工程的領域而不是微服務技術本身；
• 使用不同的通訊協議是不是區別？微服務的標桿通訊協議是RESTful，而傳統的SOA一般是SOAP，不過目前來說采用輕量級的RPC框架Dubbo、Thrift、gRPC非常多，在Spring Cloud中也有Feign框架將標準RESTful轉為代碼的API這種仿RPC的行為，這些通訊協議不應該是區分微服務架構和SOA的核心差別；
• 是流行的基於容器框架還是虛擬機為主？Docker和虛擬機還是物理機都是架構實現的一種方式，不是核心區別；

微服務架構的精髓在切分

• 服務的切分上有比較大的區別，SOA原本是以一種“集成”技術出現的，很多技術方案是將原有企業內部服務封裝為一個獨立進程，這樣新的業務開發就可重用這些服務，這些服務很可能是類似供應鏈、CRM這樣的非常大的顆粒；而微服務這個“微”，就說明了他在切分上有講究，不妥協。無數的案例證明，如果你的切分是錯誤的，那麽你得不到微服務承諾的“低耦合、升級不影響、可靠性高”之類的優勢，而會比使用Monolithic有更多的麻煩。
• 不拆分存儲的微服務是偽服務：在實踐中，我們常常見到一種架構，後端存儲是全部和在一個數據庫中，僅僅把前端的業務邏輯拆分到不同的服務進程中，本質上和一個Monolithic一樣，只是把模塊之間的進程內調用改為進程間調用，這種切分不可取，違反了分布式第一原則，模塊耦合沒有解決，性能卻受到了影響。

SOA與微服務例子

話說1979年，又是一個春天，莆田鄉下的赤腳醫生吳大牛被改革的春風吹的心潮澎湃，說幹就幹，吳大牛趁著夜色朦朧找大隊支書匯報了匯報思想，第二天就承包了村衛生室，開啟了自己的在醫療圈的傳奇歷程。

鄉村診所大家都知道，沒什麽復雜的東東，房子只有一間，一個大櫃臺中間隔開，一半是診療兼候診區，一半是藥房，看病就直接找醫生，如果前面有人就自己找個位子坐下，排隊等一會，秩序倒也井然，看完病了醫生直接給抓藥，然後下一個繼續，也不需要護士和藥劑師，吳大牛一個人全部包辦。

辛辛苦苦忙碌了十年，時間來到了八九年，又是一個春天，昔日的單身漢吳大牛已成為十裏八鄉的知名人物，媳婦娶上了不說，家裏還增加了一對雙胞胎兒子，二層的小洋房也甚是氣派。可是也有煩心事，盡管鄉村診所擴大到了兩間，媳婦還偶爾能去幫幫忙，但是醫生還是只有自己一個，天天從早忙到晚掙的都是一份錢，想多掙點怎麽辦？吳大牛日思夜想，還真給他想出來一招，怎麽辦，擴大規模，多招幾個醫生一起幹。原來吳大牛只能治頭疼腦熱和跌打損傷，現在新招了一個醫科大學的畢業生劉小明專治感冒發燒，又從鄰村請來了老大夫李阿花專治婦科病，現在一個普通的小診所就變成了有三個獨立科室加一個公共藥房（吳大牛媳婦負責）的小醫院了，吳大牛是外科主任兼院長，收入那可比之前翻了三番。人逢喜事精神爽，大牛院長請縣裏的書法名家為新醫院書寫了牌匾--“博愛醫院”，挑了一個黃道吉日正式掛了上去。

一晃十年過去了，又是一個春天，吳大牛的博愛醫院已經發展到了內科外科婦科五官科骨科生殖科六個科室，每個科室3到5名醫生不等，也耗費巨資購進了血夜化驗B超等先進儀器，大牛院長也早已脫離了醫療一線，成為了專職的管理者，但是醫院的大事小事大家都找他，就這三十多號員工搞的他每天是焦頭爛額，想再擴大規模實在是有心無力了。要說還是大學生有水平，老部下劉小明給大牛院長獻了一計，把各個科室獨立出去，讓各個科室主任自己管理，大牛院長只管科室之間的協調和醫院發展的大事，這樣既能調動基層的積極性，又能把大牛院長解放出來擴大生產抓大事謀大事，豈不妙哉？就這樣，博愛醫院的新一輪改革轟轟烈烈的展開了。

又是一個十年，又是一個春天，大牛院長已成為本地知名的企業家，博愛醫院也發展到了二十三個科室數百名員工，發展中也出現了新問題，由於各個科室獨立掛號、收費、化驗，有的科室整天忙忙碌碌效益好，有的科室就相對平庸些，連分到的各種檢查儀器都不能滿負荷運行，整個醫院養了不少閑人。這時候大牛院長視野也開闊了，請來了管理專家進行了頂層設計，把原來分散到各個科室的非核心服務全部收歸集中管理，把原來二十三個掛號窗口整合為十個，二十三個收費窗口整合為八個，集中布設在一樓大廳為全院服務，還把分散在各個科室的檢查儀器集中起來成立獨立的檢驗科，也為全院服務，這樣人人有活幹，整個醫院的服務能力又上了一個新臺階，這輪改革後博愛醫院通過了各級部門的鑒定成為了遠近馳名的三甲醫院，吳大牛也換身一變成為了博愛集團的CEO兼董事長，下一步就準備IPO上市了。

說到這裏大家可能有點糊塗，這個跟微服務有嘛關系？在孫老師看來，大牛診所的1.0階段就相當於軟件開發的單體結構，一個程序員打天下，從頭編到尾，很難做大做強。大牛診所的2.0階段就相當於軟件開發的垂直結構，各科室按照業務劃分，很容易橫向擴展。博愛醫院的1.0階段就相當於軟件開發的SOA結構，除了藥房（數據庫）外各個服務獨立提供（科室主任負責），但需要大牛院長（ESB總線）來協調。博愛醫院的2.0階段就相當於軟件開發的微服務結構，公共服務院內共享，科室主任管理功能弱化（只管醫生業務），優點是擴容方便，哪個部門缺人直接加，不用看上下遊，資源利用率高，人員和設備效率高。

SOA與微服務