前面提到的那些選擇各自都有其適用的範圍。乙個組織會選擇基於片段組裝的方式來構建 **，但對於移動應用來說，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絞殺者模式
在微服務的上下文中，通常不會使用單一的單塊應用來攔截所有對已有遺留系統的呼叫， 相反你可能會使用一系列的微服務來實施這些攔截。在這種情況下，捕獲並重定向這些原 始呼叫可能會變得更加複雜，可能需要使用乙個**來為你做這些事情。
4.16 小結
前面了解了很多不同的整合選擇，我也談了什麼樣的選擇能夠最大程度地保證微服務之間 的低耦合：
•無論如何避免資料庫整合
•理解rest和rpc之間的取捨，但總是使用rest作為請求/響應模式的起點
•相比編排，優先選擇協同
•避免破壞性修改、理解postel法則、使用容錯性讀取器
•將使用者介面視為乙個組合層
這裡覆蓋了很多內容，每個話題都不可能講得非常深入。但起碼你知道有哪些點需要學 習，以及正確的方向是什麼，這對你的進一步學習很有幫助。
我們也花了一些時間來研究如何應對那些不完全受控的系統，比如cots產品。細想一下 你會發現，這些原則也很容易應用到我們自己編寫的軟體中。
這裡列出的一些方法，對遺留系統來說同樣好用，但是如果我想要把乙個大系統分解成為 可重用的小系統，應該怎麼做呢？下一章會著重講解這個問題。
一種基於高度的材質混合方式 地表篇
發現守望先鋒的地表很特別，不像是在unity那裡畫的那種材質間線性過渡，找了一下資料，感覺像是根據高度在shader中計算的 這是一種簡單的近似方法 高度混合的原理 簡單的線性混合是這樣的，就是mix lerp一下，但是這樣很醜，不自然 得到高度圖只取最大高度的材質就是這種結果，像是泥土平鋪在石頭上...
JavaScript實現繼承的混合方式
function animal age animal.prototype.sayage function function dog age,name dog.prototype new animal dog.prototype.sayname function var dog new dog 15,...
CMMI混合型表達方式
cmmi模型最有爭議的要算是它的兩種表現方式了 階段型表現方式和連續型表現方式。階段型以自己獨特的方式展現了自己的魅力。它的最主要的特點是轉換組織的 思維方式 階段型表現方式在每提高乙個成熟度級別時，組織都要經歷一次文化的轉變。連續型表達方式，換一種說法，感覺在強制進行重新定義。在不同特徵的領域和需...