# 如何使用微服務建立財產管理系統集成 > 原文： [http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html](http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html)  *This is a guest post by Rafael Neves, Head of Enterprise Architecture at [ALICE](http://info.aliceapp.com),?a NY-based hospitality technology startup. While the domain is?**Property Management, it's also a good microservices intro.* 在零散的款待系統世界中，集成是必不可少的。 您的系統將需要與來自不同提供程序的不同系統進行交互，每個提供程序都提供自己的應用程序接口（API）。 不僅如此，而且當您與更多的酒店客戶整合時，將需要更多的實例來連接和管理此連接。 物業管理系統（PMS）是任何酒店的核心系統，隨著行業變得越來越緊密聯系，集成至關重要。 為了在酒店業提供軟件解決方案，您肯定需要與 PMS 提供者建立 2 路集成。 挑戰在于大規模建立和管理這些連接，并在多個酒店中使用多個 PMS 實例。 您可以采用幾種方法來實現這些集成。 在這里，我提出一種簡單的架構設計來構建集成基礎，隨著您的成長，該基礎將增加 ROI。 這種方法是微服務的使用。 ## 什么是微服務？ 企業軟件設計的思想領導者 Martin Fowler 提供了微服務的全面定義[：](http://martinfowler.com/articles/microservices.html) > 在過去的幾年中，出現了“微服務體系結構”一詞，用于描述將軟件應用程序設計為可獨立部署的服務套件的特定方式。 盡管沒有對此架構風格的精確定義，但圍繞業務能力，自動部署，端點中的智能以及對語言和數據的分散控制，組織周圍存在某些共同特征。 本質上，微服務是很小的軟件組件，專注于真正做好一件事情。 不必編寫一個大型的整體應用程序，而是可以使用微服務將其分解，每個微服務在給定的域中管理一個集中的功能。 因此，它們是自治的，彼此獨立執行。 因此，對一項服務的更改不應要求對另一項服務的更改。 隨著您的成長和進行更改，您無需擔心會影響其他微服務。 微服務是： * 小 * 專注于 * 松耦合 * 高凝聚力 ## 為什么微服務功能強大 微服務架構提供了很多好處。 主要優點包括： ### 可擴展性 * 您的單個系統將與具有不同屬性的多個 PMS 實例集成。 從規模上講，當與 1000 個屬性進行集成時，即使它們正在運行來自同一供應商的相同 PMS 系統，您也需要顯式管理不同的 1000 個集成。 為了增加復雜性，這些實例可以來自不同的提供程序。 * 隨著您添加許多 PMS 實例和屬性，它可以優雅地擴展。 如果您使用的是整體應用程序，則必須將所有內容擴展為一個大塊。 在流量高峰期間，可能很難理解性能瓶頸在哪里，而對于微服務而言，透明度要高得多。 * 當您擁有微服務時，很清楚哪些服務存在性能問題，您可以輕松調整其容量（底層硬件），而不必增加運行正常流量負載的其他服務的容量。 ### 彈性 * 旅館的 PMS 實例可能已關閉或出現性能問題，這不會影響系統的性能或正常運行時間。 * 您可以實現任意數量的微服務。 部署的次數越多，容錯和對更改的管理就越多。 ### 技術堆棧獨立性 * 您可以具有多個技術堆棧； 每個服務都將擁有最適合的技術堆棧。 您的訪客配置文件可能在關系數據庫中，而他們的請求可能在 NoSQL 數據庫中。 * 對特定技術棧沒有長期的承諾； 畢竟，您可以擁有多個。 ### 添加，更改或終止功能&重構 [ * 微服務非常小（通常只有幾百行代碼）。 * 由于代碼具有內聚性，因此更容易理解：它可以做一件事。 * 對其所做的更改不會直接影響其他服務。 * 刪除整個微服務更容易，并且不會對整個系統造成風險 ### 部署方式 * 酒店希望提供卓越的服務。 如果您的系統已關閉或未提供其所有功能（例如，不將來賓登機請求推送到您的 PMS 或從中讀取更新），他們將無法交付它。 * 回滾也更容易。 如果出了問題，回滾一個帶有自己數據庫的微服務要比回滾一個單個數據庫的整個系統要容易。 * 部署單片應用程序的下一版本時，總是很麻煩：即使您僅添加了一個功能，也必須立即部署整個應用程序。 一起部署所有內容都是有風險的。 ， 請記住，如果僅集成一個 PMS，則微服務是一個過大的殺傷力。 如果要與具有 1000 個不同屬性的 1000 個 PMS 實例集成，那么該體系結構的好處就顯而易見了。 ## 傳統方法：單片應用程序 借助傳統方法（整體應用程序）開始您的業務并開始新產品是很有意義的，因為它更容易。 目前，您仍在學習有關域以及域如何集成的信息。 整體更易于開發和部署，采用整體方法，則更容易回答諸如如何建模預訂服務以及如何在訪客配置文件微服務中實現訪客對帳操作之類的問題。 但是，就像您的公司一樣，整體式增長非常迅速，并且隨著系統的增長，很難擴展： 添加了新功能，推出了新的代碼行，并且當系統變得太大時，它變得難以馴服和理解。 更改系統需要進行嚴格的回歸測試，以確保新功能不會破壞系統的其他部分，因為整體應用程序通常不具有內聚力，也沒有松散耦合。 故障排除和調試更加困難，因為存在更多具有更多相互依賴性的代碼。 更新服務可能需要更改共享的基礎結構代碼，并且在引入錯誤時可能導致感染。 龐大的代碼庫使新手開發人員難以入職和培訓。 它影響部署：應用程序越大，啟動時間就越長。 是的，您可以簡單地添加更多服務器并在所有服務器上復制應用程序，但是您仍然只有一個數據庫。 不僅如此，系統的某些部分可能會更占用內存，而其他部分則需要大量 CPU。 那么，當您無法分別縮放每個組件時該怎么辦？ 您添加更多服務器！ 這是非常昂貴的。 這樣，一旦您對域有了更好的了解，就可能想要開始將系統分解為微服務。 ## 架構概述 現在，我們已經解釋了采用微服務架構的長期好處，讓我們研究一下如何設計微服務框架的一些細節： 這里的關鍵是隔離：集成的系統應該彼此獨立運行。 IE：您的核心系統獨立于在屬性 X 上運行的屬性管理系統，并且獨立于在屬性 Y 上運行的系統。 可以通過在核心系統和要與其集成的所有資產管理系統之間引入連接器（中間件）來實現這種隔離。 中間件由消息隊列和后臺工作者組成： * 可用于實現的服務示例： * 消息隊列：RabbitMQ，IronMQ 等。 * 背景工作者：IronWorker，AWS Lambda 等。 消息隊列提供系統之間的異步通信。 發件人系統（例如您的系統）將消息發布到隊列中，并一直位于該隊列中，直到后臺工作人員（訂閱該隊列）在以后處理該消息為止。 然后，后臺工作者負責處理消息（解析其內容），然后管理與 PMS API 的集成。 同樣，它將數據保存到中間件數據庫中。 請記住，后臺工作人員可以是像 AWS Lambda 這樣的云服務，也可以是內部用 Java 開發的應用程序，也可以是在 Windows 服務中開發的應用程序。 正如我們將在下面詳細介紹的那樣，微服務的技術堆棧并不重要。 請記住，一個消息隊列保證 FIFO（先進先出），因此隊列中的所有消息都按照它們進入的順序進行處理。如果您有多個隊列，則會將一條消息發布到隊列中 可以比發布到隊列 Y 的消息更早地處理 X，這在您的設計中應予以考慮。 另外，盡管 PMS 可能位于酒店的內部，但您的系統也不一定要位于云中或內部。 請記住，此服務控制與預訂關聯的所有生命周期事件，因此它不僅是 CRUD 包裝器。 如果您需要為該預訂分配房間，添加陪同客人或什至辦理入住手續，您將向該工作人員發送適當的請求。 現在讓我們根據 Martin 的描述來分析微服務的每個主要特征，以及我們的架構如何實現它們： ## 1-圍繞業務能力的組織 每個工作人員都實現了與 PMS 集成的部分邏輯。 您可以將多個工作人員插入到屬性中的同一 PMS 實例中，在其他酒店中添加更多連接到同一屬性管理系統（同一供應商）的工作人員，還可以在以下位置添加連接到不同屬性管理系統（不同供應商）的其他工作人員 其他屬性。 因此，假設您需要更改與某些 API 方法的交互方式，則只需要將新版本部署到其中一個工作程序，而不會影響其他工作程序。 您可以讓一個工人來處理預訂，另一個可以來賓。 可以在 Linux crontab 中安排一些后臺工作程序，以按照給定的時間表重復執行。 其他消息始終在運行，在到達隊列時處理消息。 其他后臺工作人員也可以回調您的核心系統 API，以插入或更新從 PMS 收集的新信息（即，從 PMS 讀取/讀取數據并將其加載到您的核心系統中）。 在薩姆·紐曼（Sam Newman）撰寫的 *Building Microservices* 一書中，他指出“在較小代碼庫上工作的較小的團隊往往生產力更高。”這是通過微服務實現的 它不僅可以提高生產率，還可以使團隊或個人從一種微服務轉移到另一種微服務（代碼庫的通用共享）。 它也可以促進創新，因為長期從事同一項目的個人或團隊可能只會提出有限范圍的新想法。 而如果您允許您的團隊在產品和項目之間切換，他們可能會提出成千上萬個新想法。 ## 2-自動部署 微服務需要以自動化方式進行部署。 為什么？ 首先，因為您有很多。 如果必須手動部署它們中的每一個，這將很容易出錯并且非常耗時。 這取決于您擁有的微服務數量。 您可以彼此獨立地分別釋放每個服務。 請注意，我的意思是在此處將新版本部署到微服務，而不是分解新的工作程序實例。 您已經在運行工作程序，但是您想部署新版本的代碼。 讓我們用一個例子說明一下： * 假設您必須與 1000 個屬性集成，其中 500 個屬性使用供應商 1（PMS_1）的 PMS，其中 500 個屬性使用供應商 2（PMS_2）的 PMS。 * 由于無論 PMS 供應商如何，這里的域上下文都非常相似，因此每個 PMS 實例將很可能具有相似數量的工作線程，除非您希望通過添加更多相同類型的工作線程來擴展給定的連接。 簡單來說，假設每個 PMS 實例有 5 個工作線程（一個用于保留，一個用于來賓配置文件，等等）。 * 由于 PMS_1 API 與 PMS_2 API 不同，因此與 PMS_1 集成的保留服務的代碼與與 PMS_2 集成的保留服務的代碼不同。 * 在 1000 個屬性上，您有 5000 個工人，然后： * 2500 名 PMS_1 員工 * 500 名預訂工人，每個屬性中帶有 PMS_1 的一名 * 500 位訪客資料工作人員，每個屬性中帶有 PMS_1 的一名 * 500 名 X 工人，每個屬性為 PMS_1 的一名工人 * 500 名 Y 工人，每個屬性為 PMS_1 的工人 * 500 名 Z 工人，每個屬性中帶有 PMS_1 的工人 * 2500 名 PMS_2 員工 * 500 名預訂工人，每個屬性中帶有 PMS_2 的一名 * 500 位訪客資料工作人員，每個屬性中帶有 PMS_2 的一名 * 500 名 X 工人，每個屬性為 PMS_2 的一名工人 * 500 名 Y 工人，每個屬性為 PMS_2 的工人 * 500 名 Z 工人，每個資產中帶有 PMS_2 的一名工人 * 假設您對與 PMS_1 集成的 Reservation 服務的代碼進行了更改，它已經過測試并且可以發布。 * 假設您最好有一個源代碼存儲庫，并在每個微服務中內置選擇的持續集成工具，這是非常明智的選擇，那么您需要將代碼部署到 500 個工作程序（與 PMS_1 集成的 500 個保留工作程序）。 其次，微服務的目的之一是要具有敏捷性，并且要具有敏捷性，您需要自動化。 這就是持續集成（CI）和持續交付（CD）的神奇之處： CI 是一種開發實踐，要求開發人員一天幾次將代碼集成到共享存儲庫中。 然后，提交觸發構建。 如果構建失敗，則每個人都會收到警報（原則上會發出偏差警報）。 此處的關鍵是盡早確定提交問題（即代碼問題）。 如果構建成功，則可以將其部署到您的應用程序服務器。 這導致我們實現持續交付： 連續交付是確保成功構建的工件可以快速部署到生產中的一種做法。 這是通過首先將您的應用程序部署到暫存環境（具有與生產環境相同的特征）來實現的。 只需按“部署”按鈕，就可以將應用程序部署到生產環境中。 最好的是，因為它只是一個按鈕，所以您無需中斷軟件工程師的工作。 * 可用于實現 CI / CD 的服務示例：Atlassian Bamboo，TeamCity，Jenkins 等。 雖然，請不要將持續交付與持續部署混淆。 我不會在這里詳細介紹它，但是我留下了 PuppetLabs 的[很棒的文章](https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff)，關于持續交付和持續部署之間的區別。 還應注意，微服務的部署比單片應用程序安全得多，這應有助于自動化。 ## 3-端點的智能 后臺工作人員封裝了如何與 PMS 集成的邏輯。 如果我們需要更改邏輯或 PMS API 已更改，我們只需要在一個地方更改-它不在您的主系統中（將其與對下游 API 的更改隔離開來）。 另外，每個 PMS 都有自己的 API，因此您可以隔離與核心系統中的每個 API 進行通信的邏輯。 ## 4-語言和數據的分散控制 每個微服務可以擁有自己的技術堆棧。 讓您擁抱技術的異質性。 例如：如果我們需要提高特定組件的性能，則可以選擇能夠實現所需性能的其他技術堆棧。 新服務不依賴于較早的技術定義，而是在適當時利用新的語言或技術。 每個工作程序可以使用不同的技術構建：工作程序 1 可以使用 Java 開發，帶有 MySQL 數據庫以處理來賓配置文件，而工作程序 2 可以使用 C＃開發，具有 NoSQL DB 來處理來賓消息。 記住：他們是獨立的。 您需要擔心它們的集成，即它們之間如何實際通信。 您將實現返回 JSON 的 RESTful API 還是使用 XML 的 SOAP API？ 現在，讓我們更深入地研究中間件。 ## 中間件 中間件提供了系統與要集成的多個屬性管理系統之間的隔離。 它由消息隊列和后臺工作者組成。 中間件不應保持狀態：兩端的系統（即您的系統和 PMS 系統）負責保持有關酒店，訪客資料，預訂等的狀態。中間件只是在兩者之間創建映射。 這樣做的原因是，您不想引入一個新的組件，該組件也存儲可能導致一致性問題的狀態：您將在 3 個不同的系統（酒店物業管理系統）中存儲相同的實體（例如，預訂）。 ，中間件和核心應用程序），并且由于集成中的某些錯誤，它們可能會有所不同。 在這種情況下，誰持有關于保留真實有效狀態的真相？ 中間件必須提供允許您協調核心系統中的內容與 PMS 中的內容的方法。 因此，如果在核心系統中創建了新請求，但是由于某種原因（實例處于脫機狀態，軟件錯誤，網絡問題等），則該請求未保存到 PMS 中（例如，向來賓作品集收費） ），中間件應提醒用戶該問題并提供重新處理集成的方法。 它必須提供清晰的視圖，以顯示每個消息在隊列中的位置以及每個后臺工作人員的狀態。 它必須允許您查看給定消息失敗及其失敗的原因，并提供重試（重新處理）給定消息的機制。 您可以在中間件數據庫的頂部具有一個緩存層，以便更快地訪問常見對象，例如城市代碼，信用卡類型等。 一些財產管理系統將此作為具有鍵-值對的枚舉來實現。 可用于提供緩存層的工具示例包括：自托管 Redis，托管 Redis 解決方案（例如 AWS Elasticache），Memcache。 ## 使用微服務的挑戰 在構建任何軟件時，尤其是在大規模集成系統中，總是存在挑戰。 紐曼在《構建微服務》一書中提醒我們，“故障成為大規模的統計確定性”，而在實現微服務時（這是整體的）肯定是這種情況。 接受一切都會失敗（硬盤，網絡等）并接受這一事實，很難處理多個獨立服務的失敗。 分布式和異步體系結構難以實現且難以調試。 您需要查看散布在多個實例中的日志，并查看分布式事務性，以了解為什么最終會出現古怪的狀態。 如果在同步工作流的中間發生錯誤，則很難回滾狀態。 了解故障發生的位置非常困難，因為工作可能并行進行，并且可能引入了難以管理的競爭條件。 確保與微服務的大規模一致性是另一個挑戰。 想象一下，您有一個管理來賓個人資料的服務，另一個服務來管理預訂。 如果新客人首次在您的酒店預訂了預訂，則預訂微服務將創建新的預訂記錄，而客人資料微服務將需要創建新的客人資料。 如果訪客個人資料存在錯誤并且未成功創建新的訪客個人資料怎么辦？ 如果管理不正確，最終將導致一個孤立的預訂，該預訂未綁定任何訪客個人資料。 從規模上講，這可能很難跟蹤和管理。 異步分布式體系結構可能會導致其他問題。 讓我們想象一下系統發送到事務處理隊列的某種類型的請求會使您的工作人員崩潰。 另外，假設您添加了多個工作程序，它們從同一隊列中提取消息以加快處理速度。 第一個工作人員從隊列中提取消息，然后死亡。 當它死亡時，對請求的鎖定將超時，并將原始請求消息放回到隊列中。 然后，您的下一個工作人員將從隊列中提取相同的消息并獲得相同的結果：消息將死亡。 另一個挑戰是，您將不得不監視不斷重新部署的數百種服務。 這將促使需要專用的 DevOps 資源或團隊來管理大量服務。 由于您有許多通過網絡進行的遠程呼叫，因此還需要考慮整體系統性能。 眾所周知，網絡不可靠：數據包可能會延遲，丟失等。此外，系統之間的消息不是實時流動的：您將消息發布到隊列中，然后在（ 不久），它將得到處理。 最后，使用微服務很難有效地實現版本控制：您最終將更改服務的接口。 您將如何處理？ 使用每種架構方法都需要權衡。 盡管微服務存在挑戰，但是每種方法都存在挑戰。 當大規模管理多個 PMS 集成時，使用微服務的好處遠遠超過成本。 **考慮大規模實施的經濟性：** 以下是實現微服務時要考慮的一些比較成本： * 大規模部署時，100 個不同的 PMS 集成可能需要 100 個服務器。 * 使用單片方法，這些服務器始終處于運行狀態。 * 在微服務世界中，微服務在需要時喚醒，在不需要時關閉。 * 借助 AWS Lambda 或 IronMQ 等云服務，您需要為 CPU 時間而非服務器時間付費。 * 當采用按需供應系統（如 Amazon Web Services 提供的系統）時，我們可以根據需要對需要的那些組件應用此擴展。 這使我們能夠更有效地控制成本。 ， 因此，隨著時間的流逝，微服務在為計算能力付費時會更具成本效益，因為有需求可以使您更緊密地管理成本并最終減少浪費。 很少有一種架構方法可以與幾乎立即節省成本緊密相關。 那么，從這里去哪里呢？ ## 拆解整體結構 我經常聽到的一個常見問題是：“我已經構建了整體應用程序。我是否需要從頭開始重新構建它以實現微服務架構？” 簡單的答案是：**否**。 長的答案是，您可以將您的整體碎片分開。 它應該是一種漸進的方法，以便您可以了解有關核心功能以及它如何與其他核心功能交互的更多信息。 這對于您了解服務應該是什么以及它們如何相互通信至關重要。 采取“邊走邊學”的方法，逐步定義系統的哪些部分應成為微服務。 我將在以后的文章中保留有關如何設計和實現此策略的詳細信息。 我希望這可以解釋其好處或使用微服務方法來構建 PMS 集成。 隨著您的系統和微服務數量的增長，這種方法將幫助您以更靈活，高效和經濟高效的方式進行擴展。 ## 相關文章 * [關于 HackerNews](https://news.ycombinator.com/item?id=11074151) * [微服務-不是免費的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) * [偉大的微服務與 Monolithic Apps Twitter 近戰](http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html) * [來自 Google 和 eBay 的關于建立微服務生態系統的深刻教訓](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html) * [生產中的微服務-好的，壞的，有效的](http://highscalability.com/blog/2014/10/27/microservices-in-production-the-good-the-bad-the-it-works.html) * [微服務中最討厭的七個反模式](http://highscalability.com/blog/2015/8/3/seven-of-the-nastiest-anti-patterns-in-microservices.html) * [改變一切的融合：數據重力+容器+微服務](http://highscalability.com/blog/2015/3/25/the-convergence-that-changes-everything-data-gravity-contain.html) * [我們如何構建更好的復雜系統？ 容器，微服務和持續交付。](http://highscalability.com/blog/2015/4/27/how-can-we-build-better-complex-systems-containers-microserv.html) 諸如此類的技術是使物業管理更加有效和高效的好方法。 我們希望將來能看到更多諸如此類的技術創新。 感謝您分享本文，這是設置此集成的不錯的教程。