作為企業(yè)與客戶以及潛在客戶的關系以及各種互動策略的管理系統(tǒng)，CRM(Customer relationshipmanagement，即關系管理)能否平穩(wěn)運轉關系著企業(yè)的運行效率和企業(yè)的盈利能力。

　　客戶關系管理的概念起源于上世紀70年代的美國，自1993年，第一款 CRM Siebel 問世以來，伴隨著信息化的發(fā)展，CRM 的概念也在逐步普及，過程中，CRM 的功能特性也在不斷豐富和完善。

　　從技術架構的角度看，80年代直到本世紀初，基本是企業(yè)本地部署為主，隨著企業(yè)的不斷發(fā)展，越來越多的 IT 資產為企業(yè)帶來了越來越高的管理負擔，隨著互聯(lián)網技術的發(fā)展，開始出現 SaaS 形式的服務。

　　CRM 的發(fā)展與技術創(chuàng)新密不可分，其背后源源不斷的驅動力則是企業(yè)的需求，企業(yè)為了生存與發(fā)展，需要不斷降本增效，需要快速響應市場變化。

　　而由于云原生技術能提升業(yè)務應用的迭代速度，賦能業(yè)務創(chuàng)新，于是便成為當下關注的焦點。

　　百度 CRM選擇百度智能云 CNAP進行微服務改造

　　百度 CRM(以下簡稱“CRM”)作為百度在營銷、銷售等領域重要的后端支撐業(yè)務方，覆蓋了售前、售中、售后全場景，能夠跟蹤客戶全生命周期，是日常工作中非常重要的系統(tǒng)。大型企業(yè)有龐大的客戶群體和龐大的業(yè)務量，對 CRM 系統(tǒng)進行任何升級改造都要非常謹慎，對于百度這種年收入千億規(guī)模的企業(yè)來說更應該慎之又慎。百度對于先進技術一直都保持著非常開放的態(tài)度，在 CRM 的規(guī)劃中，是要建立小前臺+大中臺+云后臺的產品終態(tài)，其中，云后臺已經開啟了微服務化改造的探索和實踐。

　　在百度 CRM 的微服務化改造過程中，選擇的是百度智能云的微服務產品。目前，百度智能云的微服務產品包括兩大類：一類叫做天合 Stack，這是一種可私有化部署的微服務平臺;另一類是在公有云平臺上提供的微服務平臺——CNAP。

　　從2020年第一季度開始，百度的 CRM 使用百度智能云的云原生微服務應用平臺(Cloud-Native Application Platform，以下簡稱 CNAP)來進行大規(guī)模的微服務改造，接下來，我們來對改造過程進行簡要回顧。

　　業(yè)務痛點驅動基礎架構不斷創(chuàng)新

　　百度的大型 CRM 系統(tǒng)底層需要大量硬件基礎設施，在基礎設施的管理和使用效率上，百度也在不斷優(yōu)化，以達到“降本增效”的效果。在虛擬化的技術浪潮下，基礎設施完成了虛擬化改造。使得物理硬件資源缺乏彈性、資源利用率低下、運維成本高等問題大大緩解，既實現了資源的集中化管理，也提升了架構架構的彈性擴展能力。

　　虛擬化的改造仍有許多不足，隨著 CRM 系統(tǒng)的不斷發(fā)展迭代，基礎架構層面的一些問題也越發(fā)突出：首先，在業(yè)務需求側，業(yè)務上線、迭代的速度越來越快，但研發(fā)效率并沒有相應提升;其次，在基礎設施層面，業(yè)務系統(tǒng)中的分布式基礎設施穩(wěn)定性達不到預期。同時，底層基礎設施資源的資源利用率低下，而且，系統(tǒng)變更的時效性差;第三，業(yè)務系統(tǒng)存在多種資源(物理機、虛擬機以及容器)、多種服務路由(多環(huán)境服務發(fā)現、隔離、跨環(huán)境/項目靈活的服務路由)共存的現象;第四，雖然云原生微服務化的技術帶來了解決之道，但原有微服務系統(tǒng)的服務治理和監(jiān)控需求能力不足，具體包括服務路由、服務限流以及服務熔斷，服務拓撲、調用鏈追蹤以及接口分析等多個方面。

　　微服務改造所要考慮的問題

　　云原生微服務是繼虛擬化之后，基礎架構領域的又一次革命性的創(chuàng)新，要對百度龐大的 CRM 系統(tǒng)進行微服務化改造，需要克服重重挑戰(zhàn)。

　　首先，要進行嚴肅的技術調研、技術可行性分析，要投入人員進行研發(fā)，在業(yè)務需求快速迭代的過程中，會產生一定的時間/人力成本。其次，應該意識到，微服務轉型的前提是需要業(yè)務系統(tǒng)的微服務化，微服務化會引入額外的組件，將帶來基礎組件額外的維護成本。第三，業(yè)務系統(tǒng)可能是由 Go、Java 等編程語言編寫而成，微服務轉型過程需要處理存在多編程語言共存的現狀。第四，業(yè)務遷移過程中，傳統(tǒng) Spring Cloud 微服務和新興 Service Mesh 微服務存在相互訪問的中間態(tài)。第五，業(yè)務遷移過程中存在多平臺(如物理機、虛擬機、容器)微服務應用相互訪問的中間態(tài)。

　　更有針對性的微服務解決方案

　　CNAP 微服務應用平臺提供的微服務能力主要包括：開箱即用的使用方式、微服務應用托管能力、靈活的管理模式和豐富的微服務能力四個方面。

　　結合 CNAP 微服務平臺提供的微服務能力，CRM 的微服務化改造解決方案如下所示：

　　首先，從上圖可見，百度智能云的 CNAP 為 CRM 提供了全方位的微服務能力，包括微服務注冊、服務治理、服務監(jiān)控、服務調用鏈等。其次，百度智能云的 CNAP 支持兩大微服務生態(tài)體系：Spring Cloud 微服務體系和 Service Mesh 服務網格體系。

　　在基礎設施層，通過底層網絡專線打通了包括物理機、虛擬機和容器等部署環(huán)境。在業(yè)務應用層，使用統(tǒng)一的全托管式注冊中心，實現業(yè)務云原生微服務化遷移過程中的互通。通過默認的環(huán)境隔離機制，實現服務發(fā)現過程中同環(huán)境服務發(fā)現，避免業(yè)務方跨環(huán)境發(fā)生服務調用;通過靈活的服務路由配置，實現跨項目、跨環(huán)境以及優(yōu)先級路由場景，滿足業(yè)務在地域優(yōu)先訪問、灰度發(fā)布等場景需求。

　　在可觀測性上，通過無侵入式的 Java Agent 技術，業(yè)務無感知接入微服務監(jiān)控能力，實現微服務鏈路追蹤、服務拓撲、接口分析、指標監(jiān)控等可觀測性功能。

　　微服務改造后展現多方面價值

　　在此次百度 CRM 的微服務的改造中，百度智能云 CNAP 展現出多方面的價值。首先，開箱即用的微服務體系極大地降低了部署周期。第二，統(tǒng)一運維的特性省去了單獨維護十多個微服務組件的運維成本。第三，在技術架構上，Spring Cloud 技術架構應用和 Service Mesh 技術架構應用提供底層技術支撐，既能支持當下，也面向未來。第四，業(yè)務變更效率由原來十多分鐘降低至秒級別，業(yè)務迭代速度提升。第五，資源利用率提升。資源利用率的提升也就意味著成本的降低，微服務化改造后，物理機資源成本降低了70%-80%。

　　第六，CRM 系統(tǒng)可用性大幅提升，此次改造完成后，百度 CRM 服務整體可用性超過三個9。

　　以微服務改造實踐迎接云原生技術浪潮

　　百度 CRM 的微服務化改造代表了云原生技術浪潮下，求新求變的企業(yè)在技術創(chuàng)新上的又一次成功嘗試，也展示了云原生技術作為企業(yè)數字化轉型加速器的價值。

　　百度智能云 CNAP 和天合 Stack 是百度智能云迎接云原生技術浪潮的重要抓手，在此次微服務化改造中，百度智能云 CNAP 展示的多方面價值，也體現了百度智能云在加速產業(yè)智能化方面不懈努力的一個縮影。