本文不重點介紹業務系統，更偏重于經驗分享。首先進行了業務介紹，接著和大家簡單分享了微服務，著重和大家講述了微服務的實踐，包括微服務技術實踐、微服務團隊實踐、DT下的微服務。

---

以下為內容整理：

作為全球最大的電商平臺，阿里巴巴面對的是逾4億的活躍消費者、上千萬的活躍商家、幾千種阿里自有產品和業務，以及每天上千萬筆的交易。從這些天然交易閉環里，有極其豐富的數據，如何用技術來實現用戶的“One-Click”和“One-Stop”的服務體驗？

通過微服務架構的應用，我們重構了原來臃腫低效的CRM系統，讓每個服務小團隊專注自己的業務快速迭代。同時，通過數據、模型、機器學習等智能技術手段構建全新的后臺微服務，極大的擴展了我們平臺的服務吞吐能力，即使在雙十一的特殊場景下，利用非常有限的人力，也完美承接了當天上千萬消費者的服務訴求和幾億消息的發送。

?

挑戰

我們的業務變化非常快，從最初的簡單的CRM，到現在要面對很多端很多業務，需求變化很快， 服務規模指數級增長，服務渠道需求多元化，服務內容隨著業務進一步復雜，服務體驗的標準不斷提升，開發團隊的壓力也很大，對應的挑戰就會很大。

我們希望做到“兩個One”，OneStop和OneClick，可以讓不同的業務方和商家快速接入我們的系統，也可以讓我們的“小二”快速的解決用戶問題。

大概的業務背景會分成三個層次。包括用戶進來提問會根據用戶問題做智能路由，我們會有智能機器人以人機交互的方式去解決簡單的問題，復雜問題則會根據場景智能分配給最合適的客服小二處理，同時會有一個后臺的管理系統，包括快速接入、現場管理、績效業績。

一個孤立系統的總混亂度會不斷增加。業務飛速發展讓系統應接不暇，隨之而來的噩夢也會越來越多，開發效率低、跟不上業務發展、穩定性差、代碼維護難等等，我們希望用微服務的方式把這個系統做改造升級。

?

微服務化實踐

設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。

微服務架構要求

• 分布式服務組成的系統

• 強服務個體和弱通信總線去中心化治理（SOA）

• 去中心化數據依賴

• 自動化運維（DevOps）

• 容錯

• 按照業務而不是技術來劃分組織

• 做有生命的產品而不是項目

• 快速演化

我們是逐步演進的，最早是一個大而全的CRM，最初為ORM+MVC。隨著業務發展的越來越快，我們開始用RPC，利用集團的分布式技術中間件快速解決了微服務技術上的挑戰。RPC與接下來的MSA界限已經非常小了，更重要的團隊的管理理念，按微服務化的理念來拆分團隊和系統，讓分工和開發效率更加高效。現在，我們不僅僅用Java和項目去做服務，我們用離線數據、機器學習來驅動我們的整個系統和業務的發展。我們通過Service的包裝把后臺的離線數據也暴露給系統去用，去開發所謂的智能的CRM。

微服務化技術實踐

微服務的目的是有效的拆分應用，實現敏捷開發和部署。

基于React的插件化方案

我們不僅把后臺服務拆分，前端基于React把所有的模塊分成一個個小App，這些小App可以自己去開發，只要按照前端的規范，開發之后可以嵌到我們的CRM當中，這樣在前端就把所有的系統去解耦了。

服務發現

服務發現會分成兩種模式。小型公司沒有那么多服務和應用，一般通過LoadBalancer做服務治理，用戶訪問的應用和后臺的服務都是透明的；大規模互聯網公司一般則通過客戶端做服務治理，所有的業務邏輯、服務治理在每個微服務后臺都會有一個客戶端去把自己的信息注冊上去，前臺服務在訪問時就通過服務注冊去尋找信息，如果后臺服務掛了，它也會告訴服務注冊，前臺就會知道這個服務不可用。通過這種方式可以實現流控、負載均衡等。

服務間通信（IPC）

我們希望所有的服務能夠內聚，服務之間是非常輕量級的，不要耦合在一起。通過這樣的溝通方式有：

• 同步異步調用（HTTP/RPC）：REST，Thrift，Dubbo。

• 異步消息（Notification/PubSub）：RabitMQ，Kafka， MetaQ，Notify。

保證可用性

• 懷疑第三方：有兜底，制定好業務降級方案；遵循快速失敗原則，一定要設置超時時間；適當保護第三方，慎重選擇重試機制。

• 防備使用方：設計一個好的api（RPC、Restful），避免誤用；流量控制，按服務分配流量，避免濫用。

• 做好自己：單一職責原則；控制資源的使用；避免單點。

?

微服務雖然開發簡單，技術棧靈活，服務獨立無依賴，獨立按需擴展，可用性高，但微服務是有維護成本的，數據的一致性、性能的監控、多服務運維、系統部署依賴等問題想要都解決掉是不容易的。處于不同階段的技術團隊，需要根據自己公司的技術積累和團隊的技術水平做相應的選擇。

?

微服務化團隊實踐

技術對于微服務來說從來都不是最重要的，大部分人很快就能實現設計微服務架構，理念上的轉變和團隊的管理上才是最大的挑戰。 那么怎樣去建設微服務團隊呢？

?

微服務團隊應該按照業務組織資源，建立全棧小團隊。

• 小而全團隊（含UI，DEV，DATA，TEST）。

• 通過接口明確業務邊界，無耦合（KISS? or SRP）。

• War Room自治團隊，對自己的業務負責。

• 做有生命的持續演進的產品或后臺服務，不重要的項目關停并轉。

• 對業務有使命感，不是打雜工，技術驅動業務。

• 不求完美，快速持續集成，彈性容錯。

Behavior Driven Development

BDD從業務的維度，讓PD、業務方、開發和測試能達成一致，知道要做的事情是什么，通過敏捷開發方式定義出來story，把整個復雜的PRD拆分成很小的容易理解的，然后測試人員和開發人員針對這些story去寫業務用例，這個用例不僅能做持續集成，也能變成文檔交接。

?

AI/IA as a Service

DT時代下的產品開發，基于經驗積累的工程能力變的不那么重要，而基于大數據和機器學習沉淀的模型算法變成越來越重要。未來的微服務不僅僅是Java或者工程師開發出來的，而是越來越多的由機器從海量的數據當中學習出來，他們也是我們系統自治的提供微服務的重要組成。

我們自己維護的專業的數據庫、從客戶那邊積累下的數據庫和網絡上的非結構化的數據都拉下來去做對應的數據清洗和擬合，把這些離線數據封裝出來的模型以Java服務（API）的方式暴露出來，變成我們應用的一部分。

阿里小蜜技術體系

圖為阿里小蜜問答系統，我們把數據做一些自然語言的處理后，能夠智能回答用戶的一些簡單問題，提供越來越真實和自然的人機交互。比如可以通過多輪交互的方式，更準確的理解用戶語意和真實意圖，再通過知識圖譜的構建來幫助用戶快速的找到準確的答案。

總結

以上是生活随笔為你收集整理的微服务实践：全栈小团队“洪荒之力”改造阿里服务CRM技术体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。