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

以下為內(nèi)容整理：

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

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

挑戰(zhàn)

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

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

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

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

微服務(wù)化實(shí)踐

設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。

微服務(wù)架構(gòu)要求

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

• 強(qiáng)服務(wù)個(gè)體和弱通信總線去中心化治理（SOA）

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

• 自動(dòng)化運(yùn)維（DevOps）

• 容錯(cuò)

• 按照業(yè)務(wù)而不是技術(shù)來(lái)劃分組織

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

• 快速演化

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

微服務(wù)化技術(shù)實(shí)踐

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

基于React的插件化方案

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

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

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

服務(wù)間通信（IPC）

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

• 同步異步調(diào)用（HTTP/RPC）：REST，Thrift，Dubbo。

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

保證可用性

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

• 防備使用方：設(shè)計(jì)一個(gè)好的api（RPC、Restful），避免誤用；流量控制，按服務(wù)分配流量，避免濫用。

• 做好自己：?jiǎn)我宦氊?zé)原則；控制資源的使用；避免單點(diǎn)。

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

微服務(wù)化團(tuán)隊(duì)實(shí)踐

技術(shù)對(duì)于微服務(wù)來(lái)說(shuō)從來(lái)都不是最重要的，大部分人很快就能實(shí)現(xiàn)設(shè)計(jì)微服務(wù)架構(gòu)，理念上的轉(zhuǎn)變和團(tuán)隊(duì)的管理上才是最大的挑戰(zhàn)。那么怎樣去建設(shè)微服務(wù)團(tuán)隊(duì)呢？

微服務(wù)團(tuán)隊(duì)?wèi)?yīng)該按照業(yè)務(wù)組織資源，建立全棧小團(tuán)隊(duì)。

• 小而全團(tuán)隊(duì)（含UI，DEV，DATA，TEST）。

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

• War Room自治團(tuán)隊(duì)，對(duì)自己的業(yè)務(wù)負(fù)責(zé)。

• 做有生命的持續(xù)演進(jìn)的產(chǎn)品或后臺(tái)服務(wù)，不重要的項(xiàng)目關(guān)停并轉(zhuǎn)。

• 對(duì)業(yè)務(wù)有使命感，不是打雜工，技術(shù)驅(qū)動(dòng)業(yè)務(wù)。

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

Behavior Driven Development

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

AI/IA as a Service

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

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

阿里小蜜技術(shù)體系

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

更多深度技術(shù)內(nèi)容，請(qǐng)關(guān)注云棲社區(qū)微信公眾號(hào)：yunqiinsight。