在同一臺(tái)機(jī)器上部署多個(gè)服務(wù)，上游服務(wù)只請(qǐng)求本機(jī)的下游服務(wù)，服務(wù)之間使用 http 協(xié)議傳輸 protobuf 數(shù)據(jù)，每個(gè)機(jī)器都是一個(gè)完備的投放系統(tǒng)。
這個(gè)架構(gòu)有很多的優(yōu)點(diǎn)：結(jié)構(gòu)清晰，運(yùn)維簡(jiǎn)單，網(wǎng)絡(luò)延遲最小化等。
當(dāng)然也有一些缺點(diǎn)，同一臺(tái)機(jī)器上可部署的服務(wù)數(shù)量是有限的，因而會(huì)限制架構(gòu)的增長(zhǎng)，多個(gè)模塊混合部署不利于整體的性能優(yōu)化，一個(gè)服務(wù)的異常會(huì)影響整個(gè)機(jī)器的服務(wù)質(zhì)量；這個(gè)架構(gòu)在微觀上滿足了單一服務(wù)的原則，但在宏觀上還不是真正的微服務(wù)化，為了解決上面的一些問題，按照自然的演進(jìn)我們必然走上微服務(wù)化這條路；我們從 16 年中開始進(jìn)行微服務(wù)化的實(shí)踐。
微服務(wù)化過程中我們也遇到了很多問題，分享一下我們的解決方法及效果：
1. 技術(shù)選型問題
RPC 選型，必須滿足的條件是要支持 C++、protobuf 協(xié)議和異步編程模型。最初的可選項(xiàng)有 sofa-pbrpc、pbrpc 和 grpc，這三者中我們選中了 grpc，主要看中了它通用（多語言、多平臺(tái)和支持代理）、流控、取消與超時(shí)等特性；在我們選定 grpc 之后不久百度開源了它的高性能 rpc 框架 brpc，相比之下 brpc 更具有優(yōu)勢(shì)：健全的文檔，高性能，內(nèi)置檢測(cè)服務(wù)等非常多的特性；為此我們果斷地拋棄了 grpc 和已經(jīng)在上面投入的一些開發(fā)成本，快速地展開了 brpc 相關(guān)的基礎(chǔ)功能開發(fā)和各服務(wù)的改造。
名字服務(wù)選型，排除了 zookeeper，etcd 等，最終選定的是 consul+consul template 這個(gè)組合，它很完美地支持了我們的業(yè)務(wù)需求；除服務(wù)注冊(cè)與發(fā)現(xiàn)外，還有健康檢查，服務(wù)列表本地備份，支持權(quán)重設(shè)置等功能，這些功能可以有效地減少團(tuán)隊(duì)成員的運(yùn)維工作量，增強(qiáng)系統(tǒng)的可用性，成為服務(wù)的標(biāo)準(zhǔn)配置。
2. 運(yùn)維成本增加
這是微服務(wù)化帶來的問題之一，微服務(wù)化要做服務(wù)拆分，服務(wù)節(jié)點(diǎn)的類型和數(shù)量會(huì)增多，同時(shí)還要額外運(yùn)維一些基礎(chǔ)服務(wù)（譬如，名字服務(wù)的 Agency）。考慮到大部分運(yùn)維工作都是同一個(gè)任務(wù)在多個(gè)機(jī)器上重復(fù)執(zhí)行，這樣的問題最適合交由機(jī)器來完成，所以我們的解決方案就是自動(dòng)化運(yùn)維。我們基于 Ansible 自研了一個(gè)可視化的自動(dòng)運(yùn)維系統(tǒng)。其實(shí)研發(fā)這個(gè)系統(tǒng)最初目的并不是為了支持微服務(wù)化，而是為了消除人工運(yùn)維事故，因?yàn)槿说臓顟B(tài)是不穩(wěn)定的（有時(shí)甚至是不靠譜的），所以希望由機(jī)器來替代人來完成重復(fù)的標(biāo)準(zhǔn)動(dòng)作；后來隨著微服務(wù)化的推進(jìn)，這個(gè)系統(tǒng)很自然地就接管了相關(guān)的運(yùn)維工作。現(xiàn)在這個(gè)系統(tǒng)完成了整個(gè)團(tuán)隊(duì) 90% 以上的運(yùn)維工作量。
上篇：
下篇：
甘公網(wǎng)安備 62010002000030號(hào)
