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

以下為內容整理：

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

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

挑戰(zhàn)

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

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

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

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

微服務化實踐

設計系統(tǒng)的組織，最終產(chǎn)生的設計等同于組織之內、之間的溝通結構。

微服務架構要求

• 分布式服務組成的系統(tǒng)

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

• 去中心化數(shù)據(jù)依賴

• 自動化運維（DevOps）

• 容錯

• 按照業(yè)務而不是技術來劃分組織

• 做有生命的產(chǎn)品而不是項目

• 快速演化

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

微服務化技術實踐

微服務的目的是有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署。

基于React的插件化方案

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

服務發(fā)現(xiàn)

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

服務間通信（IPC）

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

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

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

保證可用性

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

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

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

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

微服務化團隊實踐

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

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

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

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

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

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

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

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

Behavior Driven Development

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

AI/IA as a Service

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

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

阿里小蜜技術體系

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

更多深度技術內容，請關注云棲社區(qū)微信公眾號：yunqiinsight。