面向服務架構

      面向服務架構的思想在整個軟體的架構中已經不是什麼新鮮的東西。我簡單地認為服務化是模組化的延伸，所以服務化有著和模組化類似的優點和缺點。無論你採用哪種協議定義服務與服務之間的通訊方式(如WebServices.私有協議等)，這並不是服務化的本質所在，即使Java語言用RMI進行服務與服務之間的通訊也仍然不違背服務化的宗旨。

    為什麼需要面向服務架構

      1.我覺得面向服務的根本好處是便於管理，也是應用大到一定時候的必然產物。這往往和組織架構之間相契合。其實不合理的服務劃分也會帶來服務之間的混亂。

     2. 面向服務是一個解耦的過程，鬆耦合降低了服務之間的依賴，也意味著服務一個服務出現故障的時候不容易引起連鎖反應，也能更好的控制服務與服務之間的關係與優先順序。

     3.不同語言之間的通訊。

       SOA

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

      傳統的Web (HTMLHTTP)技術有效地解決了人與資訊系統的互動和溝通問題，極大的促進了B2C模式的發展。WEB服務(XMLSOAP/WSDL)技術則是要有效的解決資訊系統之間的互動和溝通問題，促進B2B/EAICB2C的發展。SOA (面向服務的體系)則是採用面向服務的商業建模技術和WEB服務技術，實現系統之間的鬆耦合，實現系統之間的整合與協同。WEB服務和SOA的本質思路在於使得資訊系統個體在能夠溝通的基礎上形成協同工作。

      對於面向同步和非同步應用的，基於請求/響應模式的分散式計算來說，SOA是一場革命。一個應用程式的業務邏輯(business logic)或某些單獨的功能被模組化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的鬆耦合特性。例如，服務的介面和實現相獨立。應用開發人員或者系統整合者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用。NET或J2EE來實現，而使用該服務的應用程式可以在不同的平臺之上，使用的語言也可以不同。

      SOA具有的特性

      SOA服務具有平臺獨立的自我描述XML文件。Web服務描述語言(WSDL, Web ServicesDescription Language)是用於描述服務的標準語言。

      SOA服務用訊息進行通訊，該訊息通常使用XML Schema來定義(也叫作XSD, XML SchemaDefinition)。.消費者和提供者或消費者和服務之間的通訊多見於不知道提供者的環境中。服務間的通訊也可以看作企業內部處理的關鍵商業文件。

      在一個企業內部, SOA服務通過一 個扮演目錄列表( drectory listing)角色的登記處( Regitry)來進行維護。應用程式在登記處(Registry)尋找並呼叫某項服務。統一描述， 定義和整合(UDDI，Universal Description, Definition, and Integration)是服務登記的標準。

      每項SOA服務都有一個與之相關的服務品質(QoS, quality of servce). QoS的一些關鍵元素有安全需求(例如認證和授權)，可靠通訊(可靠訊息是指，確保訊息僅傳送一次， 從而過濾重複資訊。)，以及誰能呼叫服務的策略。

  SOA三大基本特徵

1)獨立的功能實體

      在Internet這樣鬆散的使用環境中，任何訪問請求都有可能出錯，因此任何企圖通過Intermet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的元件技術如.NET Remoting, EJB， COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主執行結束時這些元件的壽命也隨之結束。這樣當宿主本身或者其他功能部分出現問題的時候，在該宿主上執行的其他應用服務就會受到影響。

      SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction),訊息佇列(Message Queue),冗餘部署(Redundant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。

      2)大資料量低頻率訪問

      對於.NET Remoting, EJB 或者XML-RPC這些傳統的分散式計算模型而言，他們的服務提供都是通過函式呼叫的方式進行的，一個功能的完成往往需要通過客戶端和伺服器來回很多次函式呼叫才能完成。在Intranet的環境下，這些呼叫給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet 環境下這些因素往往是決定整個系統是否能正常工作的一一個關鍵決定因素。因此SOA系統推薦採用大資料量的方式一次性進行資訊交換。

      3)基於文字的訊息傳遞

      由於Intemet中大量異構系統的存在決定了SOA系統必須採用基於文字而非二進位制的訊息傳遞方式。在COM、CORBA這些傳統的元件模型中，從伺服器端傳往客戶端的是一一個二進位制編碼的物件，在客戶端通過呼叫這個物件的方法來完成某些功能;但是在Internet 環境下，不同語言，不同平臺對資料、甚至是-一些基本資料型別定義不同，給不同的服務之間傳遞物件帶來的很大困難。由於基於文字的訊息本身是不包含任何處理邏輯和資料型別的，因此服務間只傳遞文字，對資料的處理依賴於接收端的方式可以幫忙繞過相容性這個的大泥坑。

      此外，對於一個服務來說，Intermet 與區域網最大的一個區別就是在Intemet. 上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文字的訊息傳遞方式，資料處理端可以只選擇性的處理自己理解的那部分資料，而忽略其他的資料，從而得到的非常理想的相容性。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     微服務架構( Microservices )

      對微服務架構我們沒有一個明確的定義，但簡單來說微服務架構是採用一組服務 的方式來構建一個應用，服務獨立部署在不同的程序中，不同服務通過一些輕 量級互動機制來通訊,例如RPC、HTTP等，服務可獨立擴充套件伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的程式語言來實現，由獨立的團隊來維護。

      微服務架構特徵(Charateristics) 包括如下這些特點:

      1)通過服務實現元件化

      傳統實現元件的方式是通過庫(library), 傳統元件是和應用一起執行在程序中，元件的區域性變化意味著整個應用的重新部署。  通過服務來實現元件，意味著將應用拆散為一系列的服務執行在不同的程序中，那麼單一服務的區域性變化只需重新部署對應的服務程序。另外將服務作為元件可以更明確地定義出元件的邊界，因為服務之間的呼叫是跨程序的，清晰的邊界和職責定義是設計時必須考慮的。

      2)按業務能力來劃分服務與組織團隊

      康威定律(Conway's law)指出，任何設計系統的組織，最終產生的設計等同於組織之內、之間的溝通結構。

      傳統開發方式中，我們將工程師按技能專長分層為前端層、中間層、資料層，前端對應的角色為UI、頁面構建師等，中間層對應的角色為服務端業務開發工程師，資料層對應著DBA等角色。  事實上傳統應用設計架構的分層結構正反映了不同角色的溝通結構。而 微服務架構的開發模式不同於傳統方式，它將應用按業務能力來劃分為不同的服務，每個服務都要求在對應業務領域的全棧(從前端到後端)軟體實現，從介面到資料儲存到外部溝通協作等。  因此團隊的組織是跨功能的，包含實現業務所需的全面的技能。近年 興起的全棧工程師正是因為架構和開發模式的轉變而出現，當然具備全棧的工程師其實很少，但將不同領域的工程師組織為一一個全棧的團隊就容易得多。

      3)服務即產品

      傳統的應用開發都是基於專案模式的，開發團隊根據- -堆功能列表開發出一個軟體應用並交付給客戶後，該軟體應用就進入維護模式，由另一個維護團隊負責，開發團隊的職責結束。而微服務架構的倡導者提議避免採用這種專案模式，更傾向於讓開發團隊負責整個產品的全部生命週期。Amazon 對此提出了一個觀點:

      開發團隊對軟體在生產環境的執行負全部責任，讓服務的開發者與服務的使用者(客戶)形成每天的交流反饋，來自直接客戶端的反饋有助於開發者提升服務的質量。

      4)智慧終端與啞管道

      微服務架構拋棄了ESB過度複雜的業務規則編排、訊息路由等。  服務作為智慧終端，所有的業務智慧邏輯在服務內部處理，而服務間的通訊儘可能的輕量化，不新增任何額外的業務規則。

      5)去中心統一化

      傳統應用中傾向採用統一 的技術平臺或產品來解決所有問題。不是每個問題都是釘子， 也不是每個解決方案都是一個錘子。  問題有其具體性，解決方案也應有其針對性。用最適合的技術方案去解決具體的問題，在大一-統的傳統應用中其實很難做到，而微服務的架構意味著，你可以針對不同的業務服務特徵選擇不同的技術平臺或產品，有針對性的解決具體的業務問題。

      6)基礎設施自動化

      單一程序的傳統應用被拆分為一 系列的多程序服務後，意味著開發、除錯、測試、整合、監控和釋出的複雜度都會相應增大。必須要有 合適的自動化基礎設施來支援微服務架構模式，否則開發、運維成本將大大增加。

      7) Design for failure

      正因為將服務獨立在不同的程序中後，引入了額外的失敗因素。  任何時刻對服務的呼叫都可能因為服務方不可用導致失敗，這就要求服務的消費方需要優雅的處理此類錯誤。這其實是相對傳統應用開發方式的一一個缺點，不過隨著一些開源服 務化框架的出現，對業務開發人員而言適當的遮蔽了類似的錯誤處理，不過開發人員依然需要知道對服務的呼叫是完全不同於程序內的方法或函式呼叫的。

      8)進化設計

      一旦採用了微服務架構模式，那麼在服務需要變更時我們要特別小心，服務提供者的變更可能引發服務消費者的相容性破壞，時刻謹記保持服務契約(介面)的相容性。對於解耦服務消費方和服務提供方，伯斯塔爾法則(Postel's law)特別適用，即傳送時要保守，接收時要開放。

      按照伯斯塔爾法則的思想來設計實現服務呼叫時，傳送的資料要更保守，意味著最小化的傳送必要的資訊，接收時更開放意味著要最大限度的容忍資訊的相容性。多 餘的資訊不認識可以忽略，而不應該拒絕或丟擲錯誤。

      微服務架構應用

      採用微服務架構面臨的第一個問題就是如何將一個單一應用拆分為多 個服務。有一個一般的原則是，單一服務提供的功能是可以獨立被替換和升級的。也就是說如果有A和B兩個功能，如果A功能發生變化時同時B功能也需要變化,那麼A和B這兩個功能應該被劃在一個服務中。

      微服務架構應用的成功經驗近年已越來越多，例如國外的Amazon, Netflix, 國內如阿里都採用微服務架構取得了很多正面的成功案例。但通過 上文所述微服務架構特徵看出，其實微服務架構模式有利有弊，需要根據實際的業務、團隊、環境進行仔細權衡利弊。其中 的服務拆分帶來的額外開發、測試、運維、監控的複雜度，在現有的環境、團隊下是否能夠很好的支援。

      另外，有人可能會說，我一開始不採用微服務架構方式，而是在單一程序內 基於清晰定義的模組化方式，模組之間通過介面呼叫，到了適當階段，必要的時候再將模組拆分為服務。其實這個想法顯得過於理想，因為程序內良好定義的介面通常不是很好的服務化介面。一 開始沒有考慮服務化的設計方法，那麼後期拆分時依然是一個痛苦的過程。

      總的來說，面向服務架構是一種思想，當然對於大系統而言其利必大於弊，而系統比較小的時候盲目的拆分和服務化其實會導致整個維護成本上升。系統架構並沒有一成不變的套路，也不必完全遵循某種模式。一切都在實際應用中結合具體的應用場景。應該說是“方法論”的具體產物。