一应役、面向服務設計的原則
- 服務可復用：不管是否存在即時復用的機會噩凹，服務均被設計為支持潛在的可復用
- 服務共享一個標準契約：為了與服務提供者交互广辰，消費者需要導入服務提供者的服務契約炭懊，這個契約可以是一個IDL文件票渠，Java接口定義翩活，WSDL文件阱洪，甚至是接口說明文檔
- 服務是松耦合的：服務被設計為功能相對獨立，盡量不依賴其他服務的獨立功能提供者
- 服務是底層邏輯的抽象：只有經(jīng)服務契約所暴露的服務隊外部世界可見菠镇，契約之外底層的實現(xiàn)邏輯是不可見的
- 服務是可組合冗荸、可編排的：多個服務可能被編排組合成一個新的服務，這允許不同邏輯抽象的自由組合利耍，促進服務的復用
- 服務是自治的：邏輯由服務所控制蚌本，并位于一個清晰的邊界內，服務已經(jīng)在邊界內被控制隘梨，不依賴其他服務
- 服務是無狀態(tài)的：服務應當不需要管理狀態(tài)信息程癌，因此能夠維持送耦合性。服務應該被盡可能設計成無狀態(tài)轴猎，即便意味著要將狀態(tài)管理移至他處
- 服務是可被自動發(fā)現(xiàn)的：服務發(fā)布上線后嵌莉，允許被其他消費者自動發(fā)現(xiàn)；當服務提供者下線后捻脖，允許消費者接收服務下線通知锐峭。
二中鼠、服務治理
SOA服務化之后，應用服務化之后給系統(tǒng)運維帶來很大挑戰(zhàn)：
- 分布式框架下的服務調用性能
- 服務化架構如何支持線性擴展
- 如何實現(xiàn)高效沿癞、實時的服務多維度監(jiān)控
- 大規(guī)模分布式環(huán)境下的故障快速定界和定位
- 分布式環(huán)境下海量日志在線檢索援雇、模糊查詢
- 服務的流控、超時控制椎扬、服務升降級等管控手段
- 服務的劃分原則惫搏，如何實現(xiàn)最大程度復用
此時，SOA服務治理是關鍵盗舰。SOA服務治理主要包括如下幾個方面：
1晶府、服務定義
SOA治理最基礎的方面就是監(jiān)視服務的創(chuàng)建過程。必須對服務進行標識钻趋，描述其功能川陆，確定其行為范圍并設計其接口。創(chuàng)建服務時需要與使用這些服務的團隊進行協(xié)調蛮位，以確保服務能夠滿足消費者需求较沪，避免重復工作。
2失仁、服務生命周期管理
服務的生命周期通常有五個主要的階段尸曼。
- 計劃階段
- 測試階段
- 運行階段
- 棄用階段
- 廢棄階段
3、服務版本治理
新版本的前向兼容性萄焦，灰度發(fā)布等需要按照統(tǒng)一的策略進行管理控轿。
4、服務注冊中心
需要統(tǒng)一的服務注冊中心支持服務的訂閱發(fā)布和動態(tài)發(fā)現(xiàn)機制拂封。
5茬射、服務監(jiān)控
服務監(jiān)控中心需要對服務的調用時延、成功率冒签、吞吐率等數(shù)據(jù)進行實時采樣和匯總在抛，通過圖形化報表的形式展示，以便運維人員對服務的運行質量進行實時分析和掌控萧恕。
6刚梭、運行期服務質量保障
包括服務限流、服務遷入遷出票唆、服務升降級朴读、服務權重調整和服務超時控制等，通過運行期的動態(tài)治理惰说，可以在不重啟服務的前提下達到快速提升服務運行質量的目標磨德。
7、快速的故障定界定位手段
- 大規(guī)模分布式環(huán)境下海量業(yè)務/平臺日志的采集、匯總和實時在線檢索典挑，支持多維度的條件檢索酥宴、模糊查詢，可以快速的在線查看各種系統(tǒng)運行日志您觉，方便問題定位拙寡；
- 分布式消息跟蹤，通過調用鏈打通業(yè)務琳水、服務調用和異常肆糕，發(fā)現(xiàn)線上系統(tǒng)故障源；通過在線和離線調用鏈大數(shù)據(jù)分析在孝，得到鏈路各個依賴的穩(wěn)定性指標诚啃，梳理依賴鏈路風險表，識別系統(tǒng)核心功能的服務調用依賴關系私沮，評估可能的最大風險點始赎，針對性改進以預防風險，同時為容量規(guī)劃和擴容提供數(shù)據(jù)決策依據(jù)仔燕。
8造垛、服務安全
服務安全訪問策略有多種，例如可以通過動態(tài)生成令牌token的方式做安全訪問授權晰搀，服務提供者動態(tài)生成token并告知服務注冊中心五辽，由注冊中心告知是否告知消費方，這樣就能在注冊中心頁面上做復雜的授權模型外恕。
微服務架構（MSA）是一種服務化架構風格杆逗，通過將功能分散到各個離散的服務中以實現(xiàn)對解決方案的解耦。
三鳞疲、什么是微服務
微服務架構的主要特征如下：
- 原子服務：“高內聚髓迎，松耦合”
- 高密度部署:重要的服務可以獨立進程部署，非核心服務可以獨立打包建丧，合設到同一個進程中，服務被高密度部署波势。物理機部署翎朱，可在一臺服務器上部署多個服務實例進程；如果是云端部署尺铣，則可以利用LXC實現(xiàn)容器級部署拴曲，以降低部署成本，提升資源利用率凛忿。
- 敏捷交付：真正的DevOps澈灼。
- 微自治：服務足夠小，功能單一，可以獨立打包叁熔、部署委乌、升級、回滾和彈性伸縮荣回，不依賴其他服務遭贸，實現(xiàn)局部自治。
四心软、微服務架構對比SOA
兩者的主要差異如下：
- 服務拆分粒度：SOA首先要解決的是異構系統(tǒng)應用的服務化壕吹；微服務強調的是服務拆分盡可能小，最好是獨立的原子服務删铃。
- 服務依賴：傳統(tǒng)的SOA服務耳贬，由于需要重用已有的資產(chǎn)，存在大量的服務間依賴猎唁；微服務的設計理念是服務自治咒劲、功能單一獨立，避免依賴其他服務產(chǎn)生耦合胖秒，耦合會帶來更高的復雜度缎患。
- 服務規(guī)模：傳統(tǒng)SOA服務粒度比較大，多數(shù)會采用將多個服務合并打成war包的方案阎肝，因此服務實例數(shù)比較有限挤渔；微服務強調盡可能拆分，同時很多服務會獨立部署风题，這將導致服務規(guī)模急劇膨脹判导，對服務治理和運維帶來新的挑戰(zhàn)。
- 架構差異：微服務化之后沛硅，服務數(shù)量的激增會引起架構質量屬性的變化眼刃，例如企業(yè)集成總線ESB逐漸被P2P的虛擬總線替代；為了保證高性能摇肌、低時延擂红，需要高性能的分布式服務框架保證微服務架構的實施。
- 服務治理：傳統(tǒng)基于SOA Governance的靜態(tài)治理轉型為服務運行態(tài)微治理围小、實時生效昵骤。
- 敏捷交付：服務由小研發(fā)團隊負責微服務設計、開發(fā)肯适、測試变秦、部署、線上治理框舔、灰度發(fā)布和下線蹦玫，運維整個生命周期支撐赎婚，實現(xiàn)真正的DevOps。
總結：量變引起質變樱溉，這就是微服務架構和SOA服務化架構的最大差異挣输。
