javasoa架構

1. SOA和微服務架構的區別

SOA與微服務架構，在架構劃分、技術平台選擇等方面，均存在一定的區別。

一、架構劃分不同

1、SOA強調按水平架構劃分為：前、後端、資料庫、測試等；

2、微服務強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即產品。

二、技術平台選擇不同

1、SOA應用傾向於使用統一的技術平台來解決所有問題；

2、微服務可以針對不同業務特徵選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。

三、系統間邊界處理機制不同

1、SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）；

2、微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

四、主要目標不同

1、SOA架構，主要目標是確保應用能夠交互操作；

2、微服務架構，主要目標是實現新功能、並可以快速拓展開發團隊。

參考資料

網路-SOA

網路-微服務架構

2. soa都用甚麼技術實現 java

如果對象在另外1台伺服器上，可使用Java
RMI、CORBA、DCOM等技術實現遠程調用。但是，這些技術所使用的語言及環境各不相同，很難實現互通，如何採取統1的方式進行
服務使用的是何種編

3. 初步理解一下：SOA, SOAP, Web Service, WSDL等

什麼是SOA、SOAP?

SOA到底是什麼？

SOA（Service-Oriented Architecture）的定義是面向服務的架構，就是說將軟體按照功能設計成一個個服務，這些服務用標準的方式定義介面、並通過標準的協議進行調用。 SOA所定義的介面和調用方式是獨立於編程語言和運行平台的，廣義上講SOA可以基於不同的底層技術實現，比如CORBA和Web Services。但CORBA由於過於復雜和臃腫已很少使用，所以目前所說的SOA絕大多數是基於Web Services技術實現。在Web Services的實現方式下，SOA服務的介面用XML進行定義。

在SOA架構下，軟體開發從業務流程分析開始，使用組件化業務建模的方法識別和分析各種業務模型，將各種實踐融入其中，在這個基礎上建立用例，用例直接產 生BPEL，這些BPEL則可以被融入一個服務整合框架中，其描述了各種服務的信息，從而把ESB上的各個模塊統一起來，形成一個巨大的服務倉。

將中間層再進行抽離，在中間層作一個跨技術架構的元數據和業務邏輯，使之成為跨技術架構的、可長期繼承、並不斷積累的企業業務庫和最寶貴的信息資產，也就 是面向服務的組件庫，而且這個服務組件庫也可以被其它企業復用，且不依賴於任何一種技術架構。誇張一點說，如果所有軟體企業都使用SOA架構，那麼世界軟 件業將會發生徹底的改變。顯然，這樣一個框架不是一種產品，也不僅僅是一種技術，而是一種解決問題的方法論。

SOA可能應用於兩個場景：第一種是業務互通互聯；第二種是封閉交易系統，即將元數據和業務邏輯抽離，形成可復用。舉個例子，在第一種場景中，當不同企業 之間的業務需要相互調用，這時就可能採用SOA技術；在第二種場景中，在企業內部需要將系統進行遷移時，利用SOA技術定義的原有數據和業務流程，可以很 快完成。

SOA並不是一個新事物，IT組織已經成功建立並實施SOA應用軟體很多年了，BEA、IBM、等廠商看到了它的價值，紛紛跟進。SOA的目標在於讓IT 變得更有彈性，以更快地響應業務單位的需求，實現實時企業（Real-Time Enterprise，這是Gartner為SOA描述的願景目標）。而BEA的CIO Rhonda早在2001年6月就提出要將BEA的IT基礎架構轉變為SOA，並且從對整個企業架構的控制能力、提升開發效率、加快開發速度、降低在客戶 化和人員技能的投入等方面取得了不錯的成績。

SOA是在計算環境下設計、開發、應用、管理分散的邏輯（服務）單元的一種規范。這個定義決定了SOA的廣泛性。SOA要求開發者從服務集成的角度來設計 應用軟體，即使這么做的利益不會馬上顯現。SOA要求開發者超越應用軟體來思考，並考慮復用現有的服務，或者檢查如何讓服務被重復利用。SOA鼓勵使用可 替代的技術和方法（例如消息機制），通過把服務聯系在一起而非編寫新代碼來構架應用。經過適當構架後，這種消息機制的應用允許公司僅通過調整原有服務模式 而非被迫進行大規模新的應用代碼的開發，使得在商業環境許可的時間內對變化的市場條件做出快速的響應。

SOA也不僅僅是一種開發的方法論--它還包含管理。例如，應用SOA後，管理者可以方便的管理這些搭建在服務平台上的企業應用，而不是管理單一的應用模 塊。其原理是，通過分析服務之間的相互調用，SOA使得公司管理人員方便的拿到什麼時候、什麼原因、哪些商業邏輯被執行的數據信息，這樣就幫助了企業管理 人員或應用架構師迭代地優化他們的企業業務流程、應用系統。

SOA的一個中心思想就是使得企業應用擺脫面向技術的解決方案的束縛，輕松應對企業商業服務變化、發展的需要。企業環境中單個應用程序是無法包容業務用戶 的（各種）需求的，即使是一個大型的ERP解決方案，仍然不能滿足這個需求在不斷膨脹、變化的缺口，對市場快速做出反應，商業用戶只能通過不斷開發新應 用、擴展現有應用程序來艱難的支撐其現有的業務需求。通過將注意力放在服務上，應用程序能夠集中起來提供更加豐富、目的性更強的商業流程。其結果就是，基 於SOA的企業應用系統通常會更加真實地反映出與業務模型的結合。服務是從業務流程的角度來看待技術的--這是從上向下看的。這種角度同一般的從可用技術 所驅動的商業視角是相反的。服務的優勢很清楚：它們會同業務流程結合在一起，因此能夠更加精確地表示業務模型、更好地支持業務流程。相反我們可以看到以應 用程序為中心的企業應用模型迫使業務用戶將其能力局限為應用程序的能力。

企業流程（enterprise process）是流經企業框架的空氣，它賦予業務模型里的組件以生命，並更加清晰地定義了它們之間的關系。流程定義了同業務模型進行交互操作的專門方 法。例如，會計可能是企業服務系統的一個組件--但是將發票寄給客戶卻是一個業務流程。服務被定義用來支持業務流程，因而貫穿整個流程始終的是：各種服務 組件在流程和邏輯實現過程中的裝配操作。理解業務流程是定製服務的關鍵所在。

有利於企業業務的集成傳統的應用集成方法（點對點集成、企業消息匯流排或中間件的集成（EAI）、基於業務流程的集成）都很復雜、昂貴，並且不靈活。這些集 成方法難於快速適應基於企業現代業務變化不斷產生的需求。基於面向服務架構 (SOA) 的應用開發和集成可以很好的解決其中的許多問題。

SOA 描述了一套完善的開發模式來幫助客戶端應用連接到服務上。這些模式定製了系列機制用於描述服務、通知及發現服務、與服務進行通信。

不同於傳統的應用集成方法，在 SOA 中，圍繞服務的所有模式都是以基於標準的技術實現的。大部分的通信中間件系統，如 RPC、CORBA、DCOM、EJB 和 RMI，也同樣如此。可是它們的實現都不是很完美的，在權衡交互性以及標準定製的可接受性方面總是存在問題。SOA 試圖排除這些缺陷。因為幾乎所有的通信中間件系統都有固定的處理模式，如RPC 的功能、CORBA 的對象等等。然而，服務既可以定義為功能，又可同時對外定義為對象、應用等等。這使得 SOA 可適應於任何現有系統，並使得系統在集成時不必刻意遵循任何特殊定製。

SOA 幫助企業信息系統遷移到"leave-and-layer"架構之上，這意味著在不用對現有的企業系統做修改的前提下，系統可對外提供 Web 服務介面，這是因為它們已經被可以提供 Web 服務介面的應用層做了一層封裝，所以在不用修改現有系統架構的情況下，SOA 可以將系統和應用迅速轉換為服務。SOA 不僅覆蓋來自於打包應用、定製應用和遺留系統中的信息，而且還覆蓋來自於如安全、內容管理、搜索等 IT 架構中的功能和數據。因為基於 SOA 的應用能很容易地從這些基礎服務架構中添加功能，所以基於SOA的應用能更快地應對市場變化，為使企業業務部門設計開發出新的功能應用。

Soap是什麼？

SOAP 是Simple Object Access Protocol（簡單對象訪問協議）的縮寫。

SOAP是一個用於分布式環境的、輕量級的、基於XML進行信息交換的通信協議.

對於Soap的理解：

第一步理解：SOAP＝HTTP＋XML

第二步理解：SOAP把XML的使用代碼化為請求和響應參數編碼模式，並用HTTP作傳輸。

SOAP是把成熟的基於HTTP的WEB技術與XML的靈活性和可擴展性組合在了一起。

第三步理解：具體地講，一個SOAP實現可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。

注意：SOAP 是一個協議，與編程語言無關。實際上，許多語言已經開始支持 SOAP，如：Java，C，C＋＋以及JavaScript。

Soap的起源？Soap解決的問題？

SOAP最初由微軟發起研究，用以解決MTS/COM資源消耗大，不夠輕巧等問題，後逐漸被IBM等巨頭接納並加入研究，現已提交W3C，成為Web Service應用傳輸標准。SOAP技術主要用於實現大量異構程序和平台之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問。

SOAP意思是簡單對象訪問協議（Simple Object Access Protocol）。的確如它的名字一樣，SOAP是很簡單的。它是一個基於XML的協議，允許程序組件和應用程序彼此使用一種標準的Internet協 議--HTTP來通訊。SOAP是一種獨立的平台，它不依賴程序語言，它是簡單的，彈性的，很容易擴展的。目前，應用程序能夠彼此使用一種基於DCOM和 CORBA技術的遠程過程調用（RPC）來進行相互通訊，但HTTP不被設計為這個目的。RPC在Internet上應用是非常困難的，它們會出現許多兼 容性和安全性的問題，因為防火牆和代理伺服器通常都會阻斷（block）這些類型的流量。應用程序之間最好的通訊方式是通過HTTP協議，因為HTTP是 支持所有Internet瀏覽器和伺服器的。基於這個目的，SOAP協議被創建出來。

SOAP（Simple Object Access Protocol ）簡單對象訪問協議是在分散或分布式的環境中交換信息的簡單的協議，是一個基於XML的協議，它包括四個部分：SOAP封裝(envelop)，封裝定義 了一個描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用於表示應用程序需要使用的數據類型的實例; SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定;SOAP綁定（binding），使用底層協議交換信息。

雖然這四個部分都作為SOAP的一部分，作為一個整體定義的，但他們在功能上是相交的、彼此獨立的。特別的，信封和編碼規則是被定義在不同的XML命名空間(namespace)中，這樣使得定義更加簡單。

什麼是CXF？

Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，現在已經正式更名為 Apache CXF 了，以下簡稱為 CXF。CXF 繼承了 Celtix 和 XFire 兩大開源項目的精華，提供了對 JAX-WS 全面的支持，並且提供了多種 Binding 、DataBinding、Transport 以及各種 Format 的支持，並且可以根據實際項目的需要，採用代碼優先（Code First）或者 WSDL 優先（WSDL First）來輕松地實現 Web Services 的發布和使用。目前它仍只是 Apache 的一個孵化項目。

Apache CXF 是一個開源的 Services 框架，CXF 幫助您利用 Frontend 編程 API 來構建和開發 Services ，像 JAX-WS 。這些 Services 可以支持多種協議，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，並且可以在多種傳輸協議上運行，比如：HTTP、JMS 或者 JBI，CXF 大大簡化了 Services 的創建，同時它繼承了 XFire 傳統，一樣可以天然地和 Spring 進行無縫集成。

CXF 包含了大量的功能特性，但是主要集中在以下幾個方面：

支持 Web Services 標准：CXF 支持多種 Web Services 標准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。

Frontends：CXF 支持多種「Frontend」編程模型，CXF 實現了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一個「simple frontend」允許客戶端和 EndPoint 的創建，而不需要 Annotation 註解。CXF 既支持 WSDL 優先開發，也支持從 Java 的代碼優先開發模式。

容易 使用： CXF 設計得更加直觀與容易使用。有大量簡單的 API 用來快速地構建代碼優先的 Services，各種 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加簡化的 XML 配置方式，等等。

支持二進制和遺留協議：CXF 的設計是一種可插撥的架構，既可以支持 XML ，也可以支持非 XML 的類型綁定，比如：JSON 和 CORBA。

我們來利用cxf創建一個簡單的webservice吧。

首先cxf 所需要的包：更具網站說明以下的包都是必須的，但是在我的實際項目中紅色部分的包並沒有用到。

大家可更具自己需求來添加適應的包。

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo-annotation.jar (Or the Sun equivalent)//

geronimo-javamail.jar (Or the Sun equivalent)//

neethi.jar

jaxb-api.jar

jaxb-impl.jar

stax-api.jar//

XmlSchema.jar

wstx-asl.jar

xml-resolver.jar

分布式應用程序和瀏覽器

研究一下當前的應用程序開發，你會發現一個絕對的傾向：人們開始偏愛基於瀏覽器的瘦客戶應用程序。這當然不是因為瘦客戶能夠提供更好的用戶界面，而是因為 它能夠避免花在桌面應用程序發布上的高成本。發布桌面應用程序成本很高，一半是因為應用程序安裝和配置的問題，另一半是因為客戶和伺服器之間通信的問題。

傳統的Windows富客戶應用程序使用DCOM來與伺服器進行通信和調用遠程對象。配置好DCOM使其在一個大型的網路中正常工作將是一個極富挑戰性的 工作，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽器所帶來的功能限制，也不願在區域網上去運行一個DCOM。在我看來，結果就是 一個發布容易，但開發難度大而且用戶界面極其受限的應用程序。極端的說，就是你花了更多的資金和時間，卻開發出從用戶看來功能更弱的應用程序。不信？問問 你的會計師對新的基於瀏覽器的會計軟體有什麼想法：絕大多數商用程序用戶希望使用更加友好的Windows用戶界面。

關於客戶端與伺服器的通信問題，一個完美的解決方法是使用HTTP協議來通信。這是因為任何運行Web瀏覽器的機器都在使用HTTP協議。同時，當前許多防火牆也配置為只允許HTTP連接。

許多商用程序還面臨另一個問題，那就是與其他程序的互操作性。如果所有的應用程序都是使用COM或.NET語言寫的，並且都運行在Windows平台上， 那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關系文件(VSAM)的形式存放，並由COBOL語言編寫的大型機程序訪問。而且，目前 還有很多商用程序繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫。現在，除了最簡單的程序之外，所有的應用程序都需要與運行在其他異構平台上的應用程序集成並進行數據交換。這樣的任 務通常都是由特殊的方法，如文件傳輸和分析，消息隊列，還有僅適用於某些情況的的API，如IBM的"高級程序到程序交流(APPC)"等來完成的。在以 前，沒有一個應用程序通信標准，是獨立於平台、組建模型和編程語言的。只有通過Web Service，客戶端和伺服器才能夠自由的用HTTP進行通信，不論兩個程序的平台和編程語言是什麼。

什麼是WebService?

Web services是建立可互操作的分布式應用程序的新平台。作為一個Windows程序員，你可能已經用COM或DCOM建立過基於組件的分布式應用程序。COM是一個非常好的組件技術，但是我們也很容易舉出COM並不能滿足要求的情況。

Web service平台是一套標准，它定義了應用程序如何在Web上實現互操作性。你可以用任何你喜歡的語言，在任何你喜歡的平台上寫Web service ，只要我們可以通過Web service標准對這些服務進行查詢和訪問。

Web service平台需要一套協議來實現分布式應用程序的創建。任何平台都有它的數據表示方法和類型系統。要實現互操作性，Web service平台必須提供一套標準的類型系統，用於溝通不同平台、編程語言和組件模型中的不同類型系統。在傳統的分布式系統中，基於界面 (interface)的平台提供了一些方法來描述界面、方法和參數（譯註：如COM和COBAR中的IDL語言）。同樣的，Web service平台也必須提供一種標准來描述Web service，讓客戶可以得到足夠的信息來調用這個Web service。最後，我們還必須有一種方法來對這個Web service進行遠程調用。這種方法實際是一種遠程過程調用協議(RPC)。為了達到互操作性，這種RPC協議還必須與平台和編程語言無關。

Web Service 是一種新的web應用程序分支，他們是自包含、自描述、模塊化的應用，可以發布、定位、通過web調用。Web Service可以執行從簡單的請求到復雜商務處理的任何功能。一旦部署以後，其他Web Service應用程序可以發現並調用它部署的服務。

Web Service是一種應用程序，它可以使用標準的互聯網協議，像超文本傳輸協議(HTTP)和XML，將功能綱領性地體現在互聯網和企業內部網上。可將Web服務視作Web上的組件編程。

1 歷史

web廣泛用到的技術：

◆TCP/IP：通用網路協議，被各種設備使用

◆HTML：通用用戶界面，可以使用HTML標簽顯示數據

◆Java：寫一次可以在任何地方運行的通用編程語言

◆XML ：通用數據表達語言，在web上傳送機構化數據的容易方法

他們的特點是其開放性，跨平台性，開放性正是Web services的基礎。

2 Web發展的趨勢

內容更動態化

◆帶寬Bandwidth更便宜，易於獲得

◆存儲器Storage更便宜，更易獲得

◆普遍式計算變得更加重要：大量的設備，例如行動電話，頁面，電腦，pc，已經在Internet上變得普遍，平台變得更多元化，象XML這樣的跨平台技術變得更重要

3 Web Services扮演什麼角色？

上述的這些趨勢意味著，更加智能的處理，操作和匯總內容變得十分重要。讓我們看看按照Web services角度所預示的四個趨勢：

◆內容更加動態：一個web service必須能合並從多個不同源來的內容，可以包括股票，天氣，新聞等，在傳統環境中的內容，如存貨水平，購物訂單或者目錄信息等，都從後端系統而來

◆帶寬更加便宜：web services可以分發各種類型的內容（音頻，視頻流等）

◆存儲更便宜: web services必須能聰明地處理大量數據，意味著要使用資料庫，LDAP目錄，緩沖，和負載平衡軟體等技術保持可擴展能力

◆普遍式計算更重要：web services不能要求客戶使用某一版本的windows的傳統瀏覽器，必須支持各種設備，平台，瀏覽器類型，各種內容類型。

4 兩種重要技術

要達到這樣的目標，Web services要使用兩種技術：

◆XML XML是在web上傳送結構化數據的偉大方式，Web services要以一種可靠的自動的方式操作數據，HTML不會滿足要求，而XML可以使web services十分方便的處理數據，它的內容與表示的分離十分理想

◆SOAP SOAP使用XML消息調用遠程方法，這樣web services可以通過HTTP協議的post和get方法與遠程機器交互，而且，SOAP更加健壯和靈活易用。

其他象UDDI和WSDL技術與XML和SOAP技術緊密結合用於服務發現。</SPAN>

組成Web service平台的這三個技術。

XML和XSD

可擴展的標記語言(XML)是Web service平台中表示數據的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既是平台無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟體廠商是不會選擇一個由競爭對手所發明的技術的。

XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底代表什麼？16位，32位，還是 64位？這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標准。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。Web service平台就是用XSD來作為其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，為了符合Web service標准，所有你使用的數據類型都必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換 過程。

WSDL

你會怎樣向別人介紹你的Web service有什麼功能，以及每個函數調用時的參數呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web service。解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基於XML的語言，用於描述Web service及其函數、參數和返回值。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具 既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。

4. SOA（面向服務架構）的有關知識

SOA

面向服務的體系結構（service-oriented architecture，SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯系起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。

這種具有中立的介面定義（沒有強制綁定到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程序的不同組件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。

對松耦合的系統的需要來源於業務應用程序需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作夥伴關系、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。

雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由於它考慮到了系統內的對象，所以雖然 SOA 是基於對象的，但是作為一個整體，它卻不是面向對象的。不同之處在於介面本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 SOA 相似。

然而，現在的 SOA 已經有所不同了，因為它依賴於一些更新的進展，這些進展是以可擴展標記語言（eXtensible Markup Language，XML）為基礎的。通過使用基於 XML 的語言（稱為 Web 服務描述語言（Web Services Definition Language，WSDL））來描述介面，服務已經轉到更動態且更靈活的介面系統中，非以前 CORBA 中的介面描述語言（Interface Definition Language，IDL）可比了。

Web 服務並不是實現 SOA 的惟一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向消息的中間件（Message-Oriented Middleware）系統，比如 IBM 的 MQseries。但是為了建立體系結構模型，您所需要的並不只是服務描述。您需要定義整個應用程序如何在服務之間執行其工作流。您尤其需要找到業務的操作和業務中所使用的軟體的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯系起來，並且映射這兩者之間的關系。例如，給供應商付款的操作是商業流程，而更新您的零件資料庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。

此外，動態業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作夥伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間的關系的策略，這種策略常常採用服務級協定和操作策略的形式。

最後，所有這些都必須處於一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起著重要的作用。

我可以用面向服務的體系結構做什麼？

對 SOA 的需要來源於需要使業務 IT 系統變得更加靈活，以適應業務中的改變。通過允許強定義的關系和依然靈活的特定實現，IT 系統既可以利用現有系統的功能，又可以准備在以後做一些改變來滿足它們之間交互的需要。

下面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們常常需要更改設計來趕上時尚的潮流。這可能意味著不僅需要更改樣式和顏色，甚至還可能需要更換布料、製造商和可交付的產品。如果零售商和製造商之間的系統不兼容，那麼從一個供應商到另一個供應商的更換可能就是一個非常復雜的軟體流程。通過利用 WSDL 介面在操作方面的靈活性，每個公司都可以將它們的現有系統保持現狀，而僅僅匹配 WSDL 介面並制訂新的服務級協定，這樣就不必完全重構它們的軟體系統了。這是業務的水平改變，也就是說，它們改變的是合作夥伴，而所有的業務操作基本上都保持不變。這里，業務介面可以作少許改變，而內部操作卻不需要改變，之所以這樣做，僅僅是為了能夠與外部合作夥伴一起工作。

另一種形式是內部改變，在這種改變中，零售組織現在決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店，這可以看作是採用店中店（store-in-store）的業務模型。這里，雖然公司的大多數業務操作都保持不變，但是它們現在需要新的內部軟體來處理這樣的出租安排。盡管在內部軟體系統可以承受全面的檢修，但是它們需要在這樣做的同時不會對與現有的供應商系統的交互產生大的影響。在這種情況下，SOA 模型保持原封不動，而內部實現卻發生了變化。雖然可以將新的方面添加到 SOA 模型中來加入新的出租安排的職責，但是正常的零售管理系統繼續如往常一樣。

為了延續內部改變的觀念，IT 經理可能會發現，軟體的新配置還可以以另外的一種方式加以使用，比如出租粘貼海報的地方以供廣告之用。這里，新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果，並且還是一個新的機會，而這樣的新機會在以前可能是不會有的。

垂直改變也是可能的，在這種改變中，零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話，就會帶來 SOA 模型結構的顯著改變，與之一起改變的還可能有新的系統、軟體、流程以及關系。在這種情況下，SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程序和程序的角度考慮問題，這使得業務管理可以根據業務的操作清楚地確定什麼需要添加、修改或刪除。然後可以將軟體系統構造為適合業務處理的方式，而不是在許多現有的軟體平台上常常看到的其他方式。

正如您可以看到的，在這里，改變和 SOA 系統適應改變的能力是最重要的部分。對於開發人員來說，這樣的改變無論是在他們工作的范圍之內還是在他們工作的范圍之外都有可能發生，這取決於是否有改變需要知道介面是如何定義的以及它們相互之間如何進行交互。與開發人員不同的是，架構師的作用就是引起對 SOA 模型大的改變。這種分工，就是讓開發人員集中精力於創建作為服務定義的功能單元，而讓架構師和建模人員集中精力於如何將這些單元適當地組織在一起，它已經有十多年的歷史了，通常用統一建模語言（Universal Modeling Language，UML），並且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。

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

SOA有以下特性

SOA服務具有平台獨立的自我描述XML文檔。Web服務描述語言（WSDL， Web Services Description Language）是用於描述服務的標准語言。

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

在一個企業內部，SOA服務通過一個扮演目錄列表（directory listing）角色的登記處（Registry）來進行維護。應用程序在登記處（Registry）尋找並調用某項服務。統一描述，定義和集成（UDDI， Universal Description， Definition， and Integration）是服務登記的標准。

每項SOA服務都有一個與之相關的服務品質（QoS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通信（譯註：可靠消息是指，確保消息「僅且僅僅」發送一次，從而過濾重復信息。），以及誰能調用服務的策略。

為什麼選擇SOA？

不同種類的操作系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organic business）的構架。SOA憑借其松耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。

如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來創建一個供應鏈復合應用（supply chain composite application），這些現有的應用通過標准介面來提供功能。

服務架構

為了實現SOA，企業需要一個服務架構，圖2顯示了一個例子：

在圖2中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務匯流排（service bus）轉換後發送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合並在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。

SOA基礎結構

要運行，管理SOA應用程序，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支持所有的相關標准，和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。

SOAP， WSDL， UDDI

WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來注冊和查找服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送消息。SOAP是Web服務的默認機制，其他的技術為可以服務實現其他類型的綁定。一個消費者可以在UDDI注冊表（registry）查找服務，取得服務的WSDL描述，然後通過SOAP來調用服務。

WS-I Basic Profile

WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程序來測試服務在不同平台和技術上的互用性。

J2EE 和 .Net

盡管J2EE和。NET平台是開發SOA應用程序常用的平台，但SOA不僅限於此。像J2EE這類平台，不僅為開發者自然而然地參與到SOA中來提供了一個平台，還通過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規范，例如 JAXB（Java API for XML Binding），用於將XML文檔定位到Java類；JAXR（Java API for XML Registry）用來規范對UDDI注冊表（registry）的操作；XML-RPC（Java API for XML-based Remote Procere Call）在J2EE1.4中用來調用遠程服務，這使得開發和部署可移植於標准J2EE容器的Web服務變得容易，與此同時，實現了跨平台（如。NET）的服務互用。

服務品質

在企業中，關鍵任務系統（mission-critical system，譯註：關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的，那麼該系統就是該企業的關鍵任務系統。比如，電話系統對於一個電話促銷企業來說就是關鍵任務系統，而文字處理系統就不那麼關鍵了。）用來解決高級需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構作為工具來進行開發和部署應用的時候，基本的Web服務規范，像WSDL，SOAP，以及UDDI就不能滿足這些高級需求。正如前面所提到的，這些需求也稱作服務品質（QoS，quality of services）。與QoS相關的眾多規范已經由一些標准化組織（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分將會討論一些QoS服務和相關標准。

安全

Web服務安全規范用來保證消息的安全性。該規范主要包括認證交換， 消息完整性和消息保密。該規范吸引人的地方在於它藉助現有的安全標准，例如，SAML（as Security Assertion Markup Language）來實現web服務消息的安全。OASIS正致力於Web服務安全規范的制定。

可靠

在典型的SOA 環境中，服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如「僅且僅僅傳送一次」（ once-and-only-once delivery），「最多傳送一次」（ at-most-once delivery），「重復消息過濾」（plicate message elimination），「保證消息傳送」（guaranteed message delivery）等特性消息的發送和確認，在關鍵任務系統（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標准。這些標准現在都由OASIS負責。

策略

服務提供者有時候會要求服務消費者與某種策略通信。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policy assertions）。一項策略可能會包含多個斷言。WS-Policy用來標准化服務消費者和服務提供者之間的策略通信。

控制

當企業著手於服務架構時，服務可以用來整合數據倉庫（silos of data），應用程序，以及組件。整合應用意味著例如非同步通信，並行處理，數據轉換，以及校正等進程請求必須被標准化。在SOA中，進程是使用一組離散的服務創建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。

管理

隨著企業服務的增長，所使用的服務和業務進程的數量也隨之增加，一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（Web Services for Distributed Management）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。

其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標准中描述， 這些都是OASIS 的工作。

SOA 不是Web服務

在理解SOA和Web服務的關繫上，經常發生混淆。根據2003年4月的Gartner報道，Yefim V. Natis就這個問題是這樣解釋的：「Web服務是技術規范，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的介面定義標准：這是Web服務和SOA的根本聯系。」從本質上來說，SOA是一種架構模式，而Web服務是利用一組標准實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一個中立平台，來獲得服務，而且隨著越來越多的軟體商支持越來越多的Web服務規范，你會取得更好的通用性。

SOA的優勢

SOA的概念並非什麼新東西，SOA不同於現有的分布式技術之處在於大多數軟體商接受它並有可以實現SOA的平台或應用程序。SOA伴隨著無處不在的標准，為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的應用之上創建應用；SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用於新需求的現有系統。總而言之，SOA以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。

5. soa軟體架構是什麼

SOA體系架構帶來的主要觀點是業務驅動IT，即業務驅動和業務更加緊密地聯系在一起。以粗粒度的業務服務作為基礎來對公司業務進行建模，這樣就可以產生簡潔的業務和系統視圖;以業務服務為基礎來實現的IT系統更靈活、更易於重用、也更快地應對企業業務需求的變化;以業務服務為基礎，通過顯式地方式來定義、描述、實現和管理業務層次的粗粒度服務(包括業務流程)，提供了業務服務模型和相關IT業務之間提供了更好的"可追溯性"，縮小了它們之間的差距，使得業務服務的變化更容易傳遞到IT。
利用SOA構架來開發軟體平台
推薦一個很不錯的SOA架構的軟體開發平台，方正飛鴻BPMES智能信息平台，他是java和。net雙版本無縫切換的快速開發工具。而且方正飛鴻提供免費的試用版本。可以去他們官網下載。

6. JAVA 框架 BO VO BVO SOABO 在企業用的JAVA業務和視圖的對象的封裝中，常常遇到這幾個詞

BO 業務類型 對應於具體的業務，可能含有面向業務的處理過程
VO 值類型 純粹的值，基本只用於前端頁面的值綁定，框架和業務處類之間的值傳遞
BVO 包含以上兩者
SOABO SOA面向服務的架構，是一種分布式的應用架構，在其上使用的業務對象即為 SOABO

應用分層是這么著的：
終端用戶 > web前端 > mvc框架 > spring之類的服務集成，也可能是EJB、SOA之類的分布式服務集成 > 後端的真正的業務處理 > ORM之類的存儲中間件 > 真實的存儲關系資料庫之類

7. java開發,SOA和分布式有什麼區別

典點組合

PB+SYbase、DELphi+SQL、VB+SQL、ASP+SQL、JSP+SQL、
DELphi+oracle、ASP+oracleL、JSP+oracle

真實經驗，信息系統重要的不是開發工具，而是開發理念，關鍵是管理的思路，是集成化管理，還是分布是管理，管控點在那裡，是垂直管控還是水平管控。還有，企業信息管理系統的概念很模糊，它包括了ERP，CRM，OA，等等。
我在公司就用的是VBA+SQL。三家公司分布在南京、合肥、徐州，開發工具老了點，但照樣用的很好，很符合業務流程。

------------------------------------------------------------------
Access好是好，就是安全性太差，結合ASP，就算你是在內網使用，如果你將應用程序和資料庫放在一個伺服器上，又不加措施的話，稍懂點ASP的人就能把你的資料庫下載考走，ACCESS的資料庫密碼設和沒設一樣。

最好還是ASP+SQL比較安全點，如果非要用Access，採取點措施吧，例如把.mdb修改為.asp.這樣下載是載不下來了。

8. 什麼是SOA架構圖

SOA的核心主體是服務。所謂「服務（Service）」 ，從業務角度而言，服務是一個可重復的經過標准封裝的任務，例如: 檢查帳號余額;開新帳戶 等等…。SOA的目標是通過服務的流程化來實現業務的靈活性，所謂流程（Process）是由一系列相互關聯的任務所組成，實現一個具體的業務功能。一個流程可以由一系列服務來實現。

標准架構圖如下：

耦合關系

SOA架構在松耦合解耦過程也發展到了最後的境界。傳統軟體將軟體之中核心三部分網路連接、數據轉換、業務邏輯全部耦合在一個整體之中，形成「鐵板一塊」的軟體，「牽一發而動全身」，軟體就難以適應變化。分布式對象技術將連接邏輯進行分離，消息中間件將連接邏輯進行非同步處理，增加了更大的靈活性。消息代理和一些分布式對象中間件將數據轉換也進行了分離。而SOA架構，通過服務的封裝，實現了業務邏輯與網路連接、數據轉換等進行完全的解耦。

總之，從科學哲學的角度來看，SOA是一個不斷解構的過程，傳統軟體強調系統性，耦合度過高，所以需要松耦合（解耦）；SOA也是一個組件粒度的平衡，集成電路趨勢是集成度越來越高，軟體發展的趨勢是相反的過程；SOA是架構，更是方法，反映了人們對哲學思想的追求的原動力。

按照這個特性，SOA基本上來說與WebService並不是同一個概念，SOA並不一定需要WebService實現，理論上可以在其他技術體系下，實現SOA。但事實上，到目前為止，能夠實現SOA架構風格的技術就是WebService，因為它的特性和廠商的支持力度，使得WebService成為了實現SOA實現技術的事實標准。也正因為WebService技術的成熟，才使得已經提出10多年了的SOA思想和概念，得以能夠實現落地，成為一種可以使用的技術。這也就是回答了SOA和WebService的關系。

9. 用最通俗易懂的說法解釋下SOA，還有用Java web怎麼構建SOA

SOA的目的是為了解決企業內遺留系統的互連問題，遺留系統可能是基於不同技術實現的。所以要求SOA要平台、操作系統、編程語言無關。
另外通過SOA新開發的應用可以方面的利用已有的遺留系統,跨越多個部門的IT系統，打通企業內的信息流。
從上面可以看出SOA就是個組件模型，用於遺留系統之間的互聯。組件之間的互聯通過組件之間定義的介面或標准來實現，各個組件連接用的介面標准統一後，就可以平台、操作系統、編程語言無關。
SOA可以webservice實現(java，c++多種編程語言都支持webservice），可以用消息實現（對於java來說就是jms。 c++也可以http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0509_phillips/0509_phillips.html）。
ESB是SOA的一中解決方案。開源ESB產品有Apache ServiceMix、Iona FuseESB、JBossESB、MuleESB，商業的有WebSphere ESB(WESB)，WebSphere Message Broker(WMB)，DataPower[IBM有三款ESB產品];國內的金蝶也有ESB產品

10. 微服務架構是什麼現在國內能落地嗎

微服務

維基上對其定義為：一種軟體開發技術- 面向服務的體系結構（SOA）架構樣式的一種變體，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠獨立地部署到生產環境、類生產環境等。另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據上下文，選擇合適的語言、工具對其進行構建。

微服務概念的由來是怎麼樣的呢，參考維基網路英文版，簡單梳理後的微服務出現的 歷史 ：

順便說一句，這幾個人都是大名鼎鼎的，名字可能陌生，但是擺出他們的作品，相信多少是有些了解的。 Martin Flower是《重構》、《UML 精粹》的作者；Robert Martin，人稱 Bob 大叔，敏捷專家，《代碼整潔之道》、《架構整潔之道》的作者。 既然微服務是SOA架構的一種變體，那麼，談微服務，SOA就是一個跨不過去的一個話題。

SOA

SOA的全稱是「Service Oriented Architecture」，中文翻譯是「面向服務架構」，1996年，由Gartner公司最早提出SOA概念。它的誕生是有其 歷史 背景的。

同時，基於這樣的背景，Gartner公司提出了SOA的概念，並且還給了一個預言，它預言在2008年，SOA會成為一種最流行的、且佔有絕對優勢的軟體工程實踐辦法。

很多時候，我們認為SOA已經消失在江湖，實際上並非如此，許多傳統行業，比如物流、倉儲行業的系統都是採用SOA架構來構建的。

對於SOA，從圖中可以看到，它的每一項業務功能都是一個服務，都需要對外提供服務的能力，來完成企業所需的各項業務功能，也就意味著它具有對外提供開放的能力，這些能力無需定製化就可以實現。為什麼無需定製化呢，核心就在於ESB。

看到ESB的功能，是不是覺得它的功能有點似曾相識？是的，它就是微服務所需要的基礎服務。

簡而言之，微服務架構風格 ，是一種 將單個應用程序開發為一組小服務 的方法，每個小服務都 在自己的進程中運行並與輕量級機制（通常是 HTTP 資源 API）進行通信 。 這些服務是圍繞業務能力構建的，並且 可以通過全自動部署機制獨立部署 。 這些服務的集中管理最少，可以用不同的編程語言編寫並使用不同的數據存儲技術。

上面一段話是Martin Fowler關於微服務架構論文中的核心片段，從上述片段中，我們提煉出微服務架構的核心有三點：

其一是「 小服務 」，將應用拆分為一組小服務；

其二是「 在自己的進程中運行並與輕量級機制（通常是 HTTP 資源 API）進行通信 」，微服務是由獨立進程且進程之間通過輕量級機制進行通信；

其三是「 可以通過全自動部署機制獨立部署 」，也就是說每個微服務可以快速獨立部署。

其實這已經非常精確、精準的描述出了微服務的基本特徵。完全可以作為在微服務架構實踐中落地的三個參考依據與檢驗標准。

對比維度

微服務

SOA

舉例

技術本質

Smart endpoints and mb pipes

Smart pipes and mb endpoints

應用場景

互聯網行業

傳統行業或企業內部

SOA，企業OA；微服務，電商平台

服務粒度

細

較粗

服務通信

標准化，輕量級

重量級

SOA，ESB；微服務，HTTP，RCP

服務交付

快速

較慢

微服務，服務小容易升級；SOA功能集中，較難升級

最初的應用都是單體架構，所謂單體架構就是將一系列功能全部集中在一個大的應用中，比如傳統行業一般整個財務就做一個系統，將費用管理、賬務管理、薪資結算等等都集中在一起，這種架構的局限性非常明顯，不適合大規模項目的建設。

隨著軟體架構的發展，出現SOA架構，SOA將單體架構做了拆分，拆分成粗粒度的服務，同時將部分公共功能獨立出來形成ESB，它的優點是

但是由於SOA架構需要一個統一的通信交互（ESB）， 導致了介面開發增加工作量。

更進一步發展，微服務架構出現，對服務進一步的拆分，拆分成更細粒度的服務；進一步提供了架構選擇的多樣性，微服務架構主要優點是

正是因為微服務將服務拆分的更小，它同樣也帶來了一些挑戰，比如多服務運維難度增大、服務通信成本變高、數據一致性保持更難、性能監控要求提升等等。

所以業務在選擇架構的時候，應從多方面考量選擇更合適的架構。

順便說一句，這里的架構演化是指整個架構的發展 歷史 ，並不是說你的服務就一定要經過這個演化過程，只是更多的架構模式提供更多的選擇。我們在做架構演進的時候，更多的是將單體應用演進到SOA架構或者演進到微服務架構。

面向中小企業的微服務產品提供自動應答菜單、微網站生成與管理、微信CRM系統服務、微信公眾平台客服服務等綜合性的運營管理標准化服務，是多功能的微信運營管理平台。

微信管家是將企業微信公眾賬號通過技術平台接入、運營管理等方式，幫助企業向微信用戶提供更完備服務信息、用戶互動體驗、營銷效果等企業應用解決方案。

為企業客戶提供基於微信平台的客戶服務、產品推介、互動營銷、市場調查、產品訂單等運營與系統功能

你好，很開心收到邀請來回答你的問題。

除了雲計算、大數據和人工智慧三大熱門技術之外，Java被稱為「編程開發的靈魂」，而微服務架構作為以Java為基礎的高階技能，同樣不可忽視。

按照傳統的軟體開發模式，在開發項目時，通常我們會把項目創造成一個龐然大物，這個龐然大物包括一系列的小模塊，比如「用戶模塊、訂單模塊、商品模塊、支付模塊」，一旦有模塊掉了鏈子，整個項目都將Game Over!

為了解決這個問題，我們將一個大項目拆分成許多獨立的小項目，每一個獨立的小項目被稱為服務。服務之間通過介面互相訪問。即使某些服務掛掉，也不會影響其它服務的運行。這種項目架構稱為微服務架構。

微服架構是整個互聯網的框架核心，掌控了整個互聯網的主心骨，一個好的架構就能搭建一個完美的互聯網平台。因此，具有微服專業能力的架構師人才備受重視。

今年上半年，獵聘發布了《獵聘 2019 上半年中高端人才就業現狀大數據報告》，在分領域熱招數據統計中，架構師平均達到驚人的 4.28 萬元，成為熱門領域崗位薪資之最。

微服務架構系統靈活性，健壯性，擴展性好，特別適合需求變化迅速的場景。但系統復雜度高，部署，管理難度大。微服務除了開發期框架之外，還有需要一系列的運行期中間件支撐，如API網關，服務注冊中心，統一配置中心等。 目前國內比較成熟的吧，東軟有一支團隊在做，他們網站是 https://platform.neusoft.com/

1、作為企業API調用的統一出口和許可權認證中心2、作為輕量級的企業級服務匯流排替換企業原有的ESB系統3、實現所有API介面的標准化、可視化、統一化管控4、作為微服務架構的核心API網關，集成到企業微服務架構中5、作為企業與供應鏈及合作夥伴的能力輸出介面構建OpenAPI門戶6、作為企業調用第三方API(京東、淘寶)等的統一API接入平台7、打通企業內部業務系統與外部業務系統之間的通道8、實現企業已有RestAPI、WebService、Dubbo、Kafka、MQTT等介面的注冊和協議轉換