4.14.6 —種混合方式

 

前面提到的那些選擇各自都有其適用的範圍。一個組織會選擇基於片斷組裝的方式來構建 網站，但對於移動應用來講，BFF多是更好的方式。關鍵是要保持底層服務能力的內聚 性。好比，預約音樂和改變客戶信息的邏輯應該處在相應的服務中，避免這些邏輯在系統中處處散佈。將太多的邏輯放入到剛纔提到的那種中間層中是一個常見的陷阱，在實際中 須要很是當心地作權衡來避免這個問題。

 

4.15與第三方軟件集成

 

前面提到的拆分已有系統的方式針對的是咱們本身開發的系統，但若是須要處理那些不受 咱們控制的系統呢？因爲種種緣由，和咱們一塊兒工做的組織都購買了 COTS或者利用SaaS (Software as a Service,軟件即服務平臺），而一般咱們對這些系統的控制力都頗有限。那 麼如何合理地與之進行集成呢？

 

若是你正在閱讀此書，那麼你頗有可能工做在一個須要寫代碼的組織中。你可能爲內部或 者外部的用戶編寫軟件，或者二者皆有。無論怎樣，即便你所在的組織擁有很強的定製化 軟件開發的能力，你仍是須要外部組織提供的商業或者開源軟件產品。爲何會這樣呢？

 

第一，你的組織對軟件的需求幾乎不可能徹底由內部知足。考慮你使用的全部產品，從類 似Excel的辦公自動化工具到操做系統，再到工資系統。本身建立全部這些產品的工做量 是巨大的。第二，也是最重要的一點是，這樣作很是低效！本身構建郵件系統的代價要遠 遠大於使用現成的工具，即便選用的是商業工具。

 

個人客戶常常糾結這樣的問題：「應該本身作，仍是買？ 」 通常來說，我和同事的建議是， 對於通常規模的組織來講，若是某個軟件很是特殊，而且它是你的戰略性資產的話，那就 本身構建；若是不是這麼特別的話，那就購買。

 

舉個例子，通常規模的組織不會把工資系統看成它的戰略性資產，由於全世界的人領工 資的方式都大同小異。相似地，大部分組織傾向於購買現成的CMS (Content Management System,內容管理系統），由於這一類工具對它們的業務來講並非那麼關鍵。我參與過 Guardian網站的早期構建工做，定製的內容管理系統對於新聞行業來講很是關鍵，因此他 們決定本身構建。

 

因此，使用一些商業的第三方軟件是合情合理的，但不少人會逐漸開始咒罵這些系統，這 又是爲何呢？

 

4.15.1缺少控制

 

使用相似CMS和SaaS這樣的COTS產品會面臨的一個挑戰是，如何與之進行集成並對其 進行擴展，由於大部分技術決策都不受你的控制。如何與該工具進行集成？廠家決定的。 使用什麼編程語言對其進行擴展？也取決於廠家。你是否可以把該工具的配置文件存到版 本管理中，而後在持續集成中從新建立和配置該工具？這依賴於廠家所作的決定。

 

若是你足夠幸運，從開發的角度使用該工具的難易程度會成爲工具選擇流程中的一個考慮因素。但即使如此，你仍是放棄了一部分控制。因此更好的方式是，儘可能把集成和定製化 的工做放在本身可以控制的部分。

 

4.15.2定製化

 

不少企業購買的工具都聲稱能夠爲你作深度定製化。必定要當心！這些工具鏈的定製化往 往會比從頭作起還要昂貴！若是你決定購買一個產品，可是它提供的能力不徹底適合你， 也許改變組織的工做方式會比對軟件進行定製化更加合理。

 

內容管理系統可以很好地說明這種危險。我用過的不少CMS工具設計上就不支持持續集 成，其提供的API很是難用，而且底層工具很小的升級都會破壞你作的那些定製化。

 

Salesforce的問題尤爲突出。這麼多年來它一直在推 Force.com平臺，而這個平臺須要使用 一種叫做Apex的語言，該語言只能應用在 Force.com的生態系統中。

 

4.15.3意大利麪式的集成

 

另外一個挑戰是如何與工具進行集成。如前面討論過的，服務之間的集成是一件很是重要的 事情，理想狀況下應該存在一些爲數很少的標準化集成方式。但若是一個產品決定使用專 有的二進制協議，另外一個使用SOAP，還有一個使用XML-RPC，你該怎麼辦？更糟糕的 是，那些容許你直接訪問其內部數據存儲的工具，會引人前面討論過的那些耦合問題。

 

4.15.4在本身可控的平臺進行定製化

 

COTS和SAAS產品固然是有用的，但不適用於重頭開始構建系統的場景（或者說這麼作 不合理）。那麼如何解決這些挑戰呢？關鍵是把事情移到本身可控的部分作。

 

核心思想是，任何定製化都只在本身可控的平臺上進行，並限制工具的消費者的數量。爲 了更好地理解這個概念，接下來看兩個例子。

 

1.例子：CMS做爲服務

 

從個人經驗來看，CMS是一個最常常須要作定製化或者與之集成的產品。由於除非你想要 的是基本的靜態站點，不然通常的企業都但願在本身的網站上提供動態內容，好比客戶信 息或最新的產品。這些動態內容的來源一般是組織內已經存在的其餘服務。

 

CMS最多見的賣點是，你能夠對其進行定製化，從而把各類特殊的內容放進來並顯示給外 部世界。然而普通的CMS開發環境一般都很是糟糕。

 

普通的CMS提供的主要功能是內容的建立與管理。大多數CMS甚至連頁面佈局都作很差， 它們一般只提供一些可拖拽的工具，然而這並不能知足你的需求，你還須要一些懂HTML 和CSS的人來好好調整CMS模板。在其之上開發定製化代碼將會是很是糟糕的體驗。

 

那麼到底應該怎麼辦呢？你能夠選擇在CMS上面套一層本身的服務做爲對外的網站，如 圖4-11所示。這時CMS就成爲了一個服務，其職責是管理內容的建立和獲取。在本身寫 的那個前端服務中，你能夠按照本身的方式來寫代碼和作集成。你對網站的擴展具備很好 的控制力（不少商業CMS提供了本身專用的插件來處理負載），那麼就可使用更合理的 模板系統。

圖4-11:使用CMS把你本身的服務隱藏起來

 

大多數CMS還提供了建立內容的API，因此你能夠選擇把建立的這部分也使用本身的服 務包裹一層。在曾經作過的一些項目中，咱們甚至使用過一個外觀（fapde)對獲取內容 的API進行抽象。

 

前幾年，在ThoughtWorks這種模式應用得很普遍，光是我本身就作過不止一次。一個值 得注意的例子是這樣的：一個客戶想要爲他的產品製做一個網站，剛開始他想徹底在CMS 上構建這套系統，但還沒肯定使用哪一個。就在這時咱們建議了這種方式，而後開始構建前 端網站。在CMS選定以前，用一個假的靜態內容服務來替代它。後來甚至在CMS肯定之 前，直接在生產環境使用了該靜態內容服務。等到CMS終幹選好了以後，沒有作任何修 改就順利地把原來的服務給替換掉了。

 

這種方法吋以最大程度地限制CMS的使用範圍，並把定製化的工做移到你本身的技術 棧中。

 

2.例子：多職責的CRM系統

 

咱們還常常會遇到CRM (Customer Relationship Management,客戶關係管理）工具，即 使最堅強的架構師也會對它感到恐懼。這個行業的主要廠家包括Salesforce和SAP，這些 工具試圖爲你包攬全部的事情。因此這些工具可能會出現單點失敗，而且還可能會變成一 團亂七八糟的依賴。我見過的不少CRM工具的實現都是粘性（內聚性的反方向）服務的 典範。

 

這種工具的使用範圍每每一開始會比較小，但隨着時間的發展它會在你的組織中變得越來 越重要，以致於後續的方向和選擇都會圍繞它來作。但這麼重要的系統居然不是本身作 的，而是第三方廠家提供的，這是個很嚴重的問題。

 

我最近在作的一件事情就是奪回控制權。我所服務的組織意識到雖然不少事情都使用 CRM在管>裏，可是這個平臺並無帶來與其代價相對應的收益。與此同時，不少內部系 統都在使用CRM提供的差強人意的API來作集成。咱們但願對系統架進行演化，使用自 己的服務來對業務進行建模，從而爲潛在的遷移打下基礎。

 

咱們作的第一件事情是，識別出正在被CRM系統控制的核心領域概念。其中之一是「項 目」的概念，員工會被分配到不一樣的項目上。因爲多個其餘的系統須要項目的信息，因此 咱們就建立了項目服務。這個服務將項目以RESTful資源的形式暴露出來，外部系統能夠 把它們的集成點遷移到這個新的、易用的服務上來，而這個項目服務僅僅是隱藏了底層的 集成細節而已。如圖4-12所示。

圖4-12:使用外觀服務來隱藏底層的CRM

 

在本書寫做時，這項工做還在繼續進行中。持續識別出其餘CRM管理的領域概念，而後 在其之上封裝出外觀。等到遷移時機到來時，能夠查看每個外觀來決定，是本身編寫軟 件仍是使用一些現成的方式來完成這些工做。

 

4.15.5絞殺者模式

 

你一般難以徹底控制遺留系統和COTS平臺，因此當你使用它們時要考慮若是須要移除或 者繞過它們的話，應該如何操做。一個有用的模式叫做絞殺者模式（Strangler Application Pattern,  http://martinfowler.com/bliki/StranglerApplication.html)0 與在 CMS 系統前面套一層 本身的代碼很是相似，絞殺者能夠捕獲並攔截對老系統的調用。這裏你就能夠決定，是把 這些調用路由到現存的遺留代碼中仍是導向新寫的代碼中。這種方式能夠幫助咱們逐步對老系統進行替換，從而避免影響過大的重寫。

 

在微服務的上下文中，一般不會使用單一的單塊應用來攔截全部對已有遺留系統的調用， 相反你可能會使用一系列的微服務來實施這些攔截。在這種狀況下，捕獲並重定向這些原 始調用可能會變得更加複雜，可能須要使用一個代理來爲你作這些事情。

 

4.16 小結

 

前面瞭解了不少不一樣的集成選擇，我也談了什麼樣的選擇可以最大程度地保證微服務之間 的低耦合：

 

•不管如何避免數據庫集成

 

•理解REST和RPC之間的取捨，但老是使用REST做爲請求/響應模式的起點 

•相比編排，優先選擇協同

 

•避免破壞性修改、理解Postel法則、使用容錯性讀取器

 •將用戶界面視爲一個組合層

 

這裏覆蓋了不少內容，每一個話題都不可能講得很是深刻。但起碼你知道有哪些點須要學 習，以及正確的方向是什麼，這對你的進一步學習頗有幫助。

 

咱們也花了一些時間來研究如何應對那些不徹底受控的系統，好比COTS產品。細想一下 你會發現，這些原則也很容易應用到咱們本身編寫的軟件中。

 

這裏列出的一些方法，對遺留系統來講一樣好用，可是若是我想要把一個大系統分解成爲 可重用的小系統，應該怎麼作呢？下一章會着重講解這個問題。