Erlang / OTP體系結構：SOAish服務的RESTful協議

Question

讓我們想象一下，我們有一家比薩店要設計和制造的訂單處理系統。

要求是：

R1。 該系統應該與客戶端和用例無關，這意味着客戶端可以訪問該系統，而在初始設計期間並未考慮該系統。 例如，如果披薩店決定以后許多客戶使用Samsung Bada智能手機，則為Bada OS編寫客戶端將不需要重寫系統的API和系統本身。 舉例來說，如果事實證明使用iPad而不是Android設備對交付驅動程序有某種程度的優勢，那么創建iPad客戶端將很容易，並且不會以任何方式影響系統的API；

R2 可重用性，這意味着如果業務流程發生變化，可以輕松地重新配置系統，而無需重寫大量代碼。 例如，如果稍后披薩店將開始在線接受付款並由送貨司機接受現金（在接受訂單之前接受付款與接受送貨上付款），那么很容易使系統適應新的業務流程;

R3。 高可用性和容錯能力，這意味着系統應該在線並且應該接受24/7的訂單。

因此，為了滿足R3，我們可以使用Erlang / OTP並具有以下架構：

這里的問題是這種體系結構中有很多“硬編碼”功能。 例如，如果披薩店從下達訂單時的接受現金付款轉為接受在線付款，那么將需要大量時間和精力來重寫整個系統並修改系統的API。

而且，如果比薩店需要對其CRM客戶進行一些增強，那么我們將不得不再次重寫API，客戶和系統本身。

因此，以下架構旨在解決這些問題，從而幫助滿足R1，R2和R3：

系統中的每個“服務”都是具有RESTful API的Webmachine Web服務器。 這種方法具有以下優點：

• Erlang / OTP的所有優點，因為每個Web機都是一個Erlang應用程序，可以對其進行監控並可以將其放入Erlang版本中；
• 面向服務的體系結構，具有SOA的所有優點 ；
• 易於適應業務流程的變化 ；
• 易於向客戶端（例如CRM客戶端）添加新客戶端和新功能，因為客戶端可以使用系統中所有服務的RESTful API，而不是一個“中央” API（就SOA而言，服務可組合性）。

因此，從本質上講，第二張圖中提出的系統體系結構是面向服務的體系結構，其中每個服務都具有RESTful API而不是WSDL合同，並且每個服務都是Erlang / OTP應用程序。

這是我的問題：

1. 圖2：我在這里試圖重塑車輪嗎？ 我應該只堅持使用純Erlang / OTP架構嗎？ （“純Erlang”表示打包到發行版中的Erlang應用程序，它們通過gen_server：call和gen_server：cast函數調用相互通信）；
2. 您能指出建議方法中的任何缺點嗎？ （圖2）
3. 您認為像這樣的系統（圖2）維護和擴展（R1和R2）系統要比真正的Erlang / OTP系統容易嗎？
4. 這樣的系統的安全性（圖2）可能是一個問題，因為有許多入口點（不限一個入口點（圖1））開放到網絡上（所有服務的RESTful API），不是嗎？
5. 在這樣的系統中可以有幾個“編排模塊”，還是存在一些更好的做法？ （圖2中的“接受訂單”，“ CRM”和“調度訂單”服務）；
6. 就消息傳遞和協議限制而言，純Erlang / OTP（圖1）是否比該方法（圖2）具有任何優勢？ （在我之前的類似問題 gen_server：call VS HTTP RESTful調用中進行了部分討論）

Answer 1

關於SOA要記住的一點是，體系結構與技術（REST，WS *）無關。 因此，如果需要/需要時，您可以使用幾種類型的端點來獲得良好的SOA（我稱之為Edge組件 -將業務邏輯與其他方面的問題（如通信和協議）分開）。還要注意服務邊界是一個信任邊界因此，當您跨接它時，可能需要進行身份驗證和授權，跨網絡等。此外，分層（如數據和邏輯）不應驅動服務划分方式。

因此，從我在閱讀您的問題時所讀的內容來看，我可能會將服務划分為更粗糙的服務（請參見下文）。 服務邊界內的通信可以是任何東西，因為跨服務的通信使用公共API（REST或Erlang本機由您決定，但關鍵是要對其進行管理，版本控制，安全保護等）-同樣，服務可能具有采用多種技術的終結點，以便利不同的用戶（有時您會使用ESB在服務和協議之間進行調解，但是否需要取決於系統的大小和復雜性）

關於您的具體問題

• 1如上所述，我認為有一個地方可以公開比單個入口點更多的公共API，我不確定公開使用public-api作為服務的每項功能是否是正確的選擇。
• 2＆3暴露每件事的缺點是管理開銷，性能下降（例如，您必須在這些調用中進行身份驗證）。 您將獲得納米服務服務，其開銷遠遠超過其效用。

• 關於安全性要增加的一件事是，某些服務具有REST API的事實不必轉化為讓公眾可以使用該API。 在部署方面，您可以將其保留在防火牆后面，並限制對已知地址等的訪問。

  • 5可以有幾個編排模塊，但是如果您不打算使用幾個編排模塊，則可能應該考慮使用一些編排模塊（以及ESB或編排引擎），或者您可以使用基於事件的集成並獲得基於編排的集成，這種集成更加靈活（但是不太容易管理）

  • 6第一種選擇的優點是易於開發並且可能具有更好的性能（如果這是一個問題）。 隨着時間的推移，硬編碼集成層可能會變得難以維護。 如果您編寫了erlang服務，那么如果您保持它們之間的API集成和消息傳遞，那么編寫的它們應該能夠獨立發展（幸運的是，Erland通過其固有功能（例如，不變性）相對容易地實現了這一目標）

Answer 2

我將介紹第三種方式，該方式更具成本效益並且對變更反應靈敏。 該體系結構絕對應該面向服務，因為您明確擁有服務。 但是不需要將每個服務公開為Restful或WSDL定義的服務。 我不是Erlang開發人員，但我相信有一種方法可以通過消息傳遞來調用本地和遠程進程，從而避免內部調用的不必要的序列化/序列化活動。 但是有一天，您將面臨新的集成問題。 例如，您將要集成會計或物流系統。 然后，如果您根據SOA原則設計了良好的體系結構，則最大的努力將與使用RESTful前端包裝公開現有服務有關，而無需努力重構與其他服務的現有連接。 但是問題是保持職責范圍整潔。 我的意思是，每個服務都應對最初設計的活動負責。

您提到的安全問題是已知的。 例如，您應該在所有使用令牌的公開服務中進行身份驗證/授權。