開(kāi)展基于微服務(wù)架構(gòu)進(jìn)行系統(tǒng)開(kāi)發(fā)的設(shè)想

1、開(kāi)展基于微服務(wù)架構(gòu)進(jìn)行系統(tǒng)開(kāi)發(fā)的設(shè)想一、對(duì)微服務(wù)架構(gòu)的理解1、微服務(wù)架構(gòu)的概念從Martin Fowler提出的微服務(wù)的概念來(lái)看，大概可以從以下幾點(diǎn)標(biāo)準(zhǔn)來(lái)理解：?分布式服務(wù)組成的系統(tǒng)?按照業(yè)務(wù)而不是技術(shù)來(lái)劃分提供的功能?做有生命的產(chǎn)品而不是項(xiàng)目?強(qiáng)調(diào)服務(wù)個(gè)體，弱化互相之間的通信?自動(dòng)化運(yùn)維（DevOp9?容錯(cuò)?快速演化總的來(lái)說(shuō)，微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開(kāi)發(fā)和部 署。2、微服務(wù)的優(yōu)勢(shì)和不足微服務(wù)的思路是把單一的巨大應(yīng)用拆分為眾多松散耦合的微小服務(wù)，其通常是按照業(yè)務(wù)功能來(lái)分解的，每一個(gè)服務(wù)雖然微小但卻實(shí) 現(xiàn)相對(duì)完整的功能，使用私有的數(shù)據(jù)庫(kù)，可以單獨(dú)構(gòu)建和部署，某個(gè) 服務(wù)的修改和部署不

2、會(huì)影響其他正在運(yùn)行的服務(wù)，提供語(yǔ)言無(wú)關(guān)的API接口供其他模塊調(diào)用。這種風(fēng)格與傳統(tǒng)的面向服務(wù)架構(gòu)SOA比較相似，經(jīng)過(guò)多年的發(fā)展，SOAP Web Services ESB等技術(shù)出現(xiàn)使 SOA 得以實(shí)現(xiàn)，眾多廠(chǎng)商也制定了相關(guān)的標(biāo)準(zhǔn) .兩者最重要的區(qū)別在于 SOA使用復(fù)雜的ESB集成為單一應(yīng)用，而微服務(wù)是輕量級(jí)的，不使 用復(fù)雜的ESB松散耦合，可以獨(dú)立部署。微服務(wù)架構(gòu)在規(guī)模較大的應(yīng)用中具有明顯優(yōu)勢(shì)。 首先體現(xiàn)在獨(dú)立 性方面，服務(wù)是松散耦合的，有明確的系統(tǒng)邊界，各開(kāi)發(fā)人員可以并 行開(kāi)發(fā)和部署，避免了牽一發(fā)而動(dòng)全身，提高了效率。其次是技術(shù)選 擇靈活，可針對(duì)具體業(yè)務(wù)特性和團(tuán)隊(duì)技能為一個(gè)服務(wù)選擇最合適的語(yǔ)

3、言、框架和數(shù)據(jù)庫(kù)，各服務(wù)使用不同的技術(shù)，技術(shù)轉(zhuǎn)型的成本也大為 降低。再次是系統(tǒng)伸縮更自由，可針對(duì)某些服務(wù)單獨(dú)進(jìn)行伸縮，實(shí)現(xiàn) 系統(tǒng)三維度伸縮。最后是服務(wù)可獨(dú)立部署，借助自動(dòng)化構(gòu)建和部署工 具，為DevOps的實(shí)施提供更好的支持。當(dāng)然，微服務(wù)的優(yōu)勢(shì)也是有代價(jià)的。第一顯而易見(jiàn)的是性能問(wèn)題， 微服務(wù)應(yīng)用中每個(gè)服務(wù)運(yùn)行在獨(dú)立進(jìn)程中， 服務(wù)間的調(diào)用需要通過(guò)網(wǎng) 絡(luò)傳輸，當(dāng)眾多服務(wù)需要相互調(diào)用時(shí)，就要考慮網(wǎng)絡(luò)延遲對(duì)系統(tǒng)性能 的影響，一般來(lái)講通常的應(yīng)用（包含若干個(gè)微服務(wù)），系統(tǒng)響應(yīng)時(shí)間 差距不遠(yuǎn)，但當(dāng)應(yīng)用包含成百上千的服務(wù)時(shí)， 遠(yuǎn)程調(diào)用的性能損耗是 一個(gè)要解決的關(guān)鍵問(wèn)題。第二，微服務(wù)本質(zhì)上就是一個(gè)分布式應(yīng)用，

4、分布式系統(tǒng)固有的可靠性等問(wèn)題隨著微服務(wù)數(shù)量的增加變得越來(lái)越 突出。第三個(gè)也屬于分布式系統(tǒng)的問(wèn)題，如何保證數(shù)據(jù)一致性，微服 務(wù)使用非集中式的數(shù)據(jù)管理，要解決數(shù)據(jù)一致性問(wèn)題比起單體式應(yīng)用 要困難得多。故而在運(yùn)用微服務(wù)架構(gòu)的實(shí)踐中，主要面臨的就是服務(wù)間通信，服務(wù)發(fā)現(xiàn)和服務(wù)部署3個(gè)關(guān)鍵問(wèn)題二、項(xiàng)目開(kāi)發(fā)實(shí)施的現(xiàn)狀公司目前的產(chǎn)品線(xiàn)比較豐富，但每個(gè)業(yè)務(wù)系統(tǒng)相對(duì)來(lái)說(shuō)比較獨(dú) 立，對(duì)產(chǎn)品的規(guī)范開(kāi)發(fā)、統(tǒng)一管理稍顯不足，從而導(dǎo)致項(xiàng)目實(shí)施 的周期較長(zhǎng)，實(shí)施過(guò)程中需要解決的問(wèn)題也較多，人力資源的成 本不能較好的控制。1 .目前系統(tǒng)實(shí)施的模式：工程師進(jìn)場(chǎng)調(diào)研一分析業(yè)務(wù)功能的差異部 分，進(jìn)行記錄和確認(rèn)，編寫(xiě)調(diào)研/需求報(bào)告一組

5、織人員進(jìn)行二次開(kāi) 發(fā)一與用戶(hù)進(jìn)行系統(tǒng)功能確認(rèn)一進(jìn)行原始數(shù)據(jù)的初始化，編寫(xiě)操 作手冊(cè)，組織培訓(xùn)與推廣試用一驗(yàn)收2 .定制化開(kāi)發(fā)與服務(wù)是公司項(xiàng)目實(shí)施的最大特點(diǎn)，每個(gè)業(yè)務(wù)系統(tǒng)大 都是在公司原有產(chǎn)品的基礎(chǔ)上，由項(xiàng)目組成員按照學(xué)校的各項(xiàng)業(yè) 務(wù)規(guī)則進(jìn)行定制化開(kāi)發(fā)與設(shè)計(jì)。這樣做的好處是開(kāi)發(fā)出來(lái)的系統(tǒng) 能完成貼合用戶(hù)單位的實(shí)際需求，能最大限度地保證業(yè)務(wù)在后期 能較好的得到推廣與應(yīng)用，不足的地方則在于公司的產(chǎn)品因?yàn)椴?同學(xué)校間管理規(guī)則與制度的不一致，使得實(shí)現(xiàn)的功能不盡相同。3 .各個(gè)項(xiàng)目現(xiàn)場(chǎng)實(shí)現(xiàn)的業(yè)務(wù)功能、技術(shù)成果無(wú)法實(shí)現(xiàn)高效地溝通和 分享，項(xiàng)目的可移植性、可復(fù)用性不高，而各個(gè)學(xué)校的管理模式 個(gè)性化較強(qiáng)，各個(gè)業(yè)

6、務(wù)系統(tǒng)管理范圍又比較廣，從而導(dǎo)致每個(gè)項(xiàng) 目類(lèi)似業(yè)務(wù)功能無(wú)法實(shí)現(xiàn)高效率的整合與實(shí)施，降低了項(xiàng)目實(shí)施 效率。4 .目前公司缺乏一個(gè)比較成熟、完善、高效的的數(shù)據(jù)中心，各類(lèi)業(yè) 務(wù)數(shù)據(jù)的互連互通也沒(méi)有形成具有特色的產(chǎn)品化體系，業(yè)務(wù)系統(tǒng) 在運(yùn)行的過(guò)程中有較大部分的時(shí)間和資源開(kāi)銷(xiāo)在數(shù)據(jù)的頻繁交互 上。三、下一步開(kāi)展基于微服務(wù)架構(gòu)進(jìn)行系統(tǒng)開(kāi)發(fā)的設(shè)想基于對(duì)微服務(wù)架構(gòu)的理解，及公司目前在項(xiàng)目開(kāi)發(fā)、實(shí)施的現(xiàn)狀， 公司可以從以下幾個(gè)方面開(kāi)始嘗試，將現(xiàn)有開(kāi)發(fā)模式逐步向微服務(wù)架 構(gòu)模式轉(zhuǎn)變：1、對(duì)公司現(xiàn)有產(chǎn)品、系統(tǒng)進(jìn)行分析、評(píng)估，盡快梳理出各個(gè)業(yè) 務(wù)模塊的標(biāo)準(zhǔn)服務(wù)流程。在梳理的過(guò)程中，既可以對(duì)公司現(xiàn)有產(chǎn)品、 系統(tǒng)進(jìn)行必要

7、的調(diào)整與規(guī)范，又能將每一個(gè)業(yè)務(wù)模塊中最小服務(wù)單元 整理出來(lái)。2、為了在業(yè)務(wù)架構(gòu)變更的過(guò)程中不影響現(xiàn)有系統(tǒng)的開(kāi)發(fā)與實(shí)施， 并保證系統(tǒng)架構(gòu)的可回溯性，當(dāng)有新的業(yè)務(wù)需求過(guò)來(lái)時(shí)，如果可以獨(dú) 立開(kāi)發(fā)為一個(gè)服務(wù)，就單獨(dú)開(kāi)發(fā)，然后為老服務(wù)和新服務(wù)直接編寫(xiě)膠 水代碼(Glue Code)這個(gè)過(guò)程不容易，但這是分解原有業(yè)務(wù)服 務(wù)必要的第一步。3、詳細(xì)分類(lèi)識(shí)別單體型應(yīng)用中的可以分離出來(lái)當(dāng)做單獨(dú)服務(wù)的 業(yè)務(wù)模塊。擬分離出來(lái)的業(yè)務(wù)模塊可從具有如下特點(diǎn)的模塊中考慮： 兩個(gè)模塊對(duì)資源的需求是沖突的(一個(gè)是 CPU密集型、一個(gè)是IO密 集型)；授權(quán)鑒定層也適合單獨(dú)分離出一個(gè)服務(wù)。每分離出一個(gè)服務(wù)， 就需要編寫(xiě)對(duì)應(yīng)的膠水代碼來(lái)與剩下的服務(wù)通信，這樣，在逐漸演