微服務(wù)若干關(guān)鍵問題研究

鄧杰文，曹彩鳳

?

微服務(wù)若干關(guān)鍵問題研究

鄧杰文，曹彩鳳

（五邑大學(xué) 計(jì)算機(jī)學(xué)院，廣東 江門 529020）

微服務(wù)軟件架構(gòu)正處于探索和興起階段，亞馬遜、Netflix等互聯(lián)網(wǎng)巨頭的成功案例表明微服務(wù)在大規(guī)模的企業(yè)應(yīng)用中有較明顯優(yōu)勢. 本文介紹了微服務(wù)架構(gòu)的原理，分析其優(yōu)勢和不足；對微服務(wù)實(shí)踐過程中遇到的若干關(guān)鍵問題及解決方案進(jìn)行探討；為滿足一般教務(wù)系統(tǒng)彈性可伸縮的需求，設(shè)計(jì)了基于微服務(wù)的架構(gòu)方案，在架構(gòu)設(shè)計(jì)層面解決了系統(tǒng)應(yīng)用過程中出現(xiàn)的性能瓶頸問題.

微服務(wù)；軟件架構(gòu)；單體式應(yīng)用

微服務(wù)（Microservices）[1]一詞最早在2011年由威尼斯的一個(gè)軟件架構(gòu)小組提出，用以表示當(dāng)時(shí)出現(xiàn)的一種流行的軟件架構(gòu)風(fēng)格，2012年，該小組將其命名為微服務(wù). 同年，James[2]在波蘭展示了微服務(wù)的案例. Netflix公司的Adrian稱“微服務(wù)是細(xì)化的SOA，是Web領(lǐng)域一種先進(jìn)的架構(gòu)風(fēng)格”[3]. 此后，陸續(xù)有互聯(lián)網(wǎng)公司嘗試使用類似架構(gòu)并取得了成功，盡管它們不一定都稱其為微服務(wù)，典型的有Amazon[4]，Netflix[5]，Uber[6]，Groupon[7]等. 本文擬對微服務(wù)實(shí)踐中的關(guān)鍵問題進(jìn)行探討，提出解決方案，為以后微服務(wù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)提供更多理論指引.

1 微服務(wù)的定義

微服務(wù)還沒有一個(gè)統(tǒng)一的定義，Martin[8]認(rèn)為“微服務(wù)是一種軟件架構(gòu)風(fēng)格，它把復(fù)雜的應(yīng)用分解為多個(gè)微小的服務(wù)，這些服務(wù)運(yùn)行在各自的進(jìn)程中，使用與語言無關(guān)的輕量級通信機(jī)制（通常是基于HTTP的REST API）相互協(xié)調(diào)，每個(gè)服務(wù)圍繞各自的業(yè)務(wù)進(jìn)行構(gòu)建，可使用不同的編程語言和數(shù)據(jù)存儲技術(shù)，并能通過自動化機(jī)制獨(dú)立部署，這些服務(wù)應(yīng)使用最低限度的集中式服務(wù)管理機(jī)制”.

與微服務(wù)相對的是單體式（Monolithic）應(yīng)用架構(gòu)，它把所有業(yè)務(wù)作為一個(gè)整體來構(gòu)建和部署，一個(gè)典型的Web應(yīng)用可能包含了與用戶交互的前端、后端業(yè)務(wù)邏輯和數(shù)據(jù)庫3部分，盡管都會使用模塊化設(shè)計(jì)，但最終該應(yīng)用都會被構(gòu)建為一個(gè)整體來部署，運(yùn)行在單一進(jìn)程中. 如一個(gè)Java Web應(yīng)用會被打包為一個(gè)War文件部署在Tomcat中. 單體式架構(gòu)的優(yōu)點(diǎn)顯而易見：構(gòu)建、測試簡單，因?yàn)楝F(xiàn)有IDE都是針對單體應(yīng)用設(shè)計(jì)的；部署容易，只要把壓縮包拷貝到相應(yīng)目錄即可. 但當(dāng)應(yīng)用的規(guī)模越來越大時(shí)，其缺點(diǎn)就越發(fā)明顯：1）開發(fā)效率越來越低，因?yàn)閹缀鯖]有開發(fā)者能全面了解如此龐大的應(yīng)用，即使修改一行代碼也要重新編譯部署整個(gè)應(yīng)用；2）持續(xù)交付的周期越來越長，現(xiàn)今的敏捷開發(fā)要求快速響應(yīng)變化，及時(shí)獲取客戶反饋，縮短迭代周期，而單體應(yīng)用都是整體部署，所以需等各模塊均修改完成后方可交付部署，無法滿足短時(shí)間多次部署的要求；3）技術(shù)選型成本高，單體式應(yīng)用自始至終使用同一種技術(shù)棧，系統(tǒng)規(guī)模越大，轉(zhuǎn)型越困難，無法享受新技術(shù)的便利，也給開發(fā)人員的招聘帶來限制；4）可伸縮性差，對于單體應(yīng)用通常只能實(shí)現(xiàn)縱向伸縮[9]，通過部署應(yīng)用實(shí)例的集群，然后使用負(fù)載均衡器把用戶請求分發(fā)到不同節(jié)點(diǎn)上來實(shí)現(xiàn)，但如果要提高某些模塊的性能或吞吐能力，實(shí)現(xiàn)橫向伸縮則很困難，因?yàn)閱误w應(yīng)用是所有模塊整體運(yùn)行在一個(gè)進(jìn)程中的.

2 微服務(wù)的優(yōu)勢和不足

微服務(wù)的思路是把單一的巨大應(yīng)用拆分為眾多松散耦合的微小服務(wù)，其通常是按照業(yè)務(wù)功能來分解的，每一個(gè)服務(wù)雖然微小但卻實(shí)現(xiàn)相對完整的功能，使用私有的數(shù)據(jù)庫，可以單獨(dú)構(gòu)建和部署，某個(gè)服務(wù)的修改和部署不會影響其他正在運(yùn)行的服務(wù)，提供語言無關(guān)的API接口供其他模塊調(diào)用. 這種風(fēng)格與傳統(tǒng)的面向服務(wù)架構(gòu)SOA[10]比較相似，經(jīng)過多年的發(fā)展，SOAP、Web Services、ESB[11]等技術(shù)出現(xiàn)使SOA得以實(shí)現(xiàn)，眾多廠商也制定了相關(guān)的標(biāo)準(zhǔn). 兩者最重要的區(qū)別在于SOA使用復(fù)雜的ESB集成為單一應(yīng)用，而微服務(wù)是輕量級的，不使用復(fù)雜的ESB，松散耦合，可以獨(dú)立部署.

微服務(wù)架構(gòu)在規(guī)模較大的應(yīng)用中具有明顯優(yōu)勢. 首先體現(xiàn)在獨(dú)立性方面，服務(wù)是松散耦合的，有明確的系統(tǒng)邊界，各開發(fā)團(tuán)隊(duì)可以并行開發(fā)和部署，避免了牽一發(fā)而動全身，提高了效率. 其次是技術(shù)選擇靈活，可針對具體業(yè)務(wù)特性和團(tuán)隊(duì)技能為一個(gè)服務(wù)選擇最合適的語言、框架和數(shù)據(jù)庫，各服務(wù)使用不同的技術(shù)棧，技術(shù)轉(zhuǎn)型的成本也大為降低. 再次是系統(tǒng)伸縮更自由，可針對某些服務(wù)單獨(dú)進(jìn)行伸縮，實(shí)現(xiàn)系統(tǒng)三維度伸縮[12]. 最后是服務(wù)可獨(dú)立部署，借助自動化構(gòu)建和部署工具，為DevOps[13]的實(shí)施提供更好的支持.

當(dāng)然，微服務(wù)的優(yōu)勢也是有代價(jià)的. 第一顯而易見的是性能問題，微服務(wù)應(yīng)用中每個(gè)服務(wù)運(yùn)行在獨(dú)立進(jìn)程中，服務(wù)間的調(diào)用需要通過網(wǎng)絡(luò)傳輸，當(dāng)眾多服務(wù)需要相互調(diào)用時(shí)，就要考慮網(wǎng)絡(luò)延遲對系統(tǒng)性能的影響，Villamizar[14]等人研究認(rèn)為通常的應(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ù)本質(zhì)上就是一個(gè)分布式應(yīng)用，分布式系統(tǒng)固有的可靠性等問題隨著微服務(wù)數(shù)量的增加變得越來越突出. 第三個(gè)也屬于分布式系統(tǒng)的問題，如何保證數(shù)據(jù)一致性，微服務(wù)使用非集中式的數(shù)據(jù)管理，要解決數(shù)據(jù)一致性[15]問題比起單體式應(yīng)用要困難得多.

3 微服務(wù)的關(guān)鍵問題分析

采用微服務(wù)架構(gòu)的應(yīng)用是一個(gè)分布式的應(yīng)用，相對于單體式應(yīng)用其實(shí)是更復(fù)雜了，在展示出其特有的優(yōu)越性同時(shí)，還需解決好若干關(guān)鍵問題.

3.1 服務(wù)間通信問題

微服務(wù)是一個(gè)分布式系統(tǒng)，服務(wù)被部署在不同節(jié)點(diǎn)中，服務(wù)的交互需要通過網(wǎng)絡(luò)進(jìn)行通信，因此服務(wù)間如何通信是一個(gè)需考慮的問題，它會直接影響著系統(tǒng)的性能. 按交互模式分可把服務(wù)間通信分為同步的請求響應(yīng)模式與異步的消息模式兩種. 同步模式由于要等待對方響應(yīng)，所以當(dāng)有多個(gè)調(diào)用時(shí)總時(shí)延是各調(diào)用時(shí)延之和. 而異步模式由于不用等待響應(yīng)，所以總時(shí)延是各調(diào)用時(shí)延的最大者，大大改善了性能. 異步模式雖可改善響應(yīng)時(shí)間，但模式要根據(jù)實(shí)際的業(yè)務(wù)功能進(jìn)行選擇，實(shí)際的應(yīng)用經(jīng)常會同時(shí)使用這兩種模式. 同步模式實(shí)現(xiàn)可以使用基于HTTP的REST或Thrift[16]，使用REST的好處是簡單，與語言無關(guān)，開發(fā)門檻低. Thrift則支持多種語言的遠(yuǎn)程調(diào)用，可用二進(jìn)制傳輸數(shù)據(jù)，在高并發(fā)、大數(shù)據(jù)量情況下更具優(yōu)勢. 至于異步模式可借用眾多成熟的消息系統(tǒng)，如RabbitMQ、ActiveMQ、Apache Kafka等，它們都支持多種語言接口，并且提供持久化的、異步的、高性能的消息通信機(jī)制. 對于復(fù)雜的微服務(wù)應(yīng)用，使用消息系統(tǒng)的優(yōu)勢很明顯，它實(shí)現(xiàn)了服務(wù)間的解耦，并且解決了分布式系統(tǒng)中的可靠性問題. 但使用消息系統(tǒng)令開發(fā)變得更加復(fù)雜，還需要額外的配置與維護(hù)，增大了部署運(yùn)維的難度.

另一個(gè)提高服務(wù)間通信效率的方法是使用API網(wǎng)關(guān). 考慮如下場景，一個(gè)微服務(wù)應(yīng)用既支持Web網(wǎng)站又支持手機(jī)原生應(yīng)用，各微服務(wù)通過API接口對上述兩客戶端提供后臺服務(wù). 展示手機(jī)上一屏畫面可能就需要調(diào)用多個(gè)后臺微服務(wù)，因?yàn)橐苿釉O(shè)備與微服務(wù)不是處于局域網(wǎng)中且其網(wǎng)絡(luò)帶寬通常較低，這種頻繁的調(diào)用會令時(shí)延增加直至嚴(yán)重影響用戶體驗(yàn). 一種解決方法是在微服務(wù)前增加一個(gè)API網(wǎng)關(guān)服務(wù)，把多個(gè)細(xì)粒度的調(diào)用歸并為一個(gè)粗粒度的服務(wù)供客戶端調(diào)用，一次提供所有需要的結(jié)果. 由于API網(wǎng)關(guān)與其他微服務(wù)同處局域網(wǎng)，因此調(diào)用時(shí)延低且不會消耗客戶端流量. 一個(gè)微服務(wù)應(yīng)用的結(jié)構(gòu)通常如圖1所示.

圖1 微服務(wù)應(yīng)用結(jié)構(gòu)圖

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

當(dāng)一個(gè)服務(wù)需調(diào)用另一個(gè)微服務(wù)時(shí)，如何定位其網(wǎng)絡(luò)位置又是一個(gè)需解決的關(guān)鍵問題. 出于系統(tǒng)伸縮的需要，微服務(wù)會有多個(gè)實(shí)例，它們被部署在一臺或多臺虛擬機(jī)中，網(wǎng)絡(luò)位置是動態(tài)生成并有可能變動的，因此需要一種服務(wù)發(fā)現(xiàn)機(jī)制. 目前有兩種解決方案，客戶端發(fā)現(xiàn)和服務(wù)端發(fā)現(xiàn). 客戶端發(fā)現(xiàn)機(jī)制類似DNS解析，由客戶端向服務(wù)注冊表查詢服務(wù)位置，并使用負(fù)載均衡算法從返回的實(shí)例中選擇其一再向其發(fā)起調(diào)用. 服務(wù)實(shí)例啟動時(shí)向服務(wù)注冊表注冊自己的位置，并發(fā)送心跳信號表明自己沒有失效. 這種機(jī)制易于理解，但每個(gè)客戶端都需編寫服務(wù)查詢代碼. 服務(wù)端發(fā)現(xiàn)機(jī)制中，客戶端請求是發(fā)給負(fù)載均衡器的，由其查詢和選擇服務(wù)實(shí)例并轉(zhuǎn)發(fā)請求，因此客戶端無需操心服務(wù)查詢. 但負(fù)載均衡器必須是高可用的，否則容易成為系統(tǒng)瓶頸，因?yàn)樗休d了所有的請求轉(zhuǎn)發(fā). 實(shí)例的注冊也可以使用前述的自注冊方式. 還有一種第三方注冊方式，系統(tǒng)中有一個(gè)注冊管理服務(wù)負(fù)責(zé)監(jiān)控服務(wù)實(shí)例，當(dāng)有新的實(shí)例啟動時(shí)就向注冊表注冊該服務(wù)，當(dāng)實(shí)例失效時(shí)注銷該實(shí)例，這樣服務(wù)實(shí)例就免去了編寫自注冊的代碼. 但第三方注冊方式需要系統(tǒng)處于一個(gè)集中式的實(shí)例管理環(huán)境中才可行. 另外，服務(wù)注冊表本質(zhì)上是一個(gè)高可用的數(shù)據(jù)存儲，當(dāng)系統(tǒng)規(guī)模較大時(shí)需要使用集群，目前已有滿足這種分布、可靠、高可用條件的開源實(shí)現(xiàn)，如etcd[17]，consul和ZooKeeper[18].

3.3 服務(wù)部署問題

微服務(wù)的部署方式是另一個(gè)關(guān)鍵問題，有幾種常見的方法：第1種是微服務(wù)實(shí)例都部署在一臺或多臺虛擬機(jī)或物理主機(jī)中，不需特別的隔離方法，只要保證每個(gè)微服務(wù)擁有不同的網(wǎng)絡(luò)端口或位置即可. 如Java Web應(yīng)用可以讓多個(gè)微服務(wù)的War文件都部署在同一個(gè)Tomcat中. 這種方法簡單直接，共享系統(tǒng)資源，利用率最高，但缺點(diǎn)是由于服務(wù)間沒有隔離，某個(gè)服務(wù)的崩潰可能會影響其他服務(wù)的正常運(yùn)行，或者某個(gè)服務(wù)錯(cuò)誤地掠奪了共享的系統(tǒng)資源；第2種方法是讓每個(gè)微服務(wù)實(shí)例運(yùn)行在單獨(dú)的虛擬機(jī)中，這種方法隔離最徹底，相互不受影響，并可以控制每臺虛擬機(jī)使用資源的額度，對某個(gè)服務(wù)進(jìn)行伸縮也很簡單，缺點(diǎn)是虛擬機(jī)啟動較慢，且較消耗系統(tǒng)資源；第3種方法得益于容器[19]技術(shù)如Docker[20]的發(fā)展，是讓每個(gè)微服務(wù)實(shí)例運(yùn)行在一個(gè)容器中，每臺虛擬機(jī)可運(yùn)行一個(gè)或多個(gè)容器實(shí)例. 容器屬于操作系統(tǒng)層面的虛擬化，提供了類似虛擬機(jī)的隔離環(huán)境，但卻共享操作系統(tǒng)內(nèi)核，其占用資源少，啟動速度快. 這種方法的優(yōu)點(diǎn)是使得服務(wù)間能相互隔離，系統(tǒng)的資源利用率也較高. 對于這種方法可以使用容器集群系統(tǒng)來進(jìn)行管理，常用的有Google Kubernetes[21]、Docker Swarm和Mesos，它們兼具了服務(wù)發(fā)現(xiàn)功能，大大減輕了微服務(wù)部署和伸縮的難度. 這3種方法都能應(yīng)對系統(tǒng)伸縮的要求，需要擴(kuò)展某服務(wù)性能時(shí)，只需部署更多實(shí)例就可以了.

4 方案應(yīng)用

針對一般教務(wù)系統(tǒng)應(yīng)用過程中出現(xiàn)的性能瓶頸問題，對其核心架構(gòu)進(jìn)行設(shè)計(jì). 教務(wù)系統(tǒng)用戶可分為3類：學(xué)生、教師與教輔人員，學(xué)生主要使用場景是評教選課與成績查詢，教師主要使用場景是成績錄入與開課查詢，教輔人員主要使用場景是教務(wù)信息管理等. 評教選課與成績查詢集中在開學(xué)初與學(xué)期末，由于學(xué)生人數(shù)眾多，使用時(shí)間高度集中，因而系統(tǒng)負(fù)載很高，但其余時(shí)間訪問卻幾乎為零. 教師成績錄入也是高度集中在學(xué)期末. 因此，需要使用一種可單獨(dú)對這些服務(wù)彈性伸縮的方案，以提高資源利用率，微服務(wù)架構(gòu)可以滿足以上需求，系統(tǒng)核心架構(gòu)如圖2所示.

圖2 教務(wù)系統(tǒng)核心架構(gòu)圖

教務(wù)系統(tǒng)分解為評教選課服務(wù)、開課查詢服務(wù)、成績錄入服務(wù)、成績查詢服務(wù)及其他若干服務(wù). 采用每個(gè)服務(wù)實(shí)例部署在一個(gè)Docker容器的部署方式，以提高系統(tǒng)資源利用率，容器則運(yùn)行在云主機(jī)或物理主機(jī)中. 由于需要容器集群，所以選用了Kubernetes這個(gè)開源的容器集群管理系統(tǒng). Kubernetes屬于集中式的容器管理環(huán)境，它使用etcd實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)功能，只要做一些配置即可解決服務(wù)發(fā)現(xiàn)問題，各服務(wù)無需自己實(shí)現(xiàn)服務(wù)注冊、查詢功能，適合教務(wù)系統(tǒng)這種規(guī)模較小的應(yīng)用. 評教選課與成績錄入服務(wù)類似，在特定時(shí)段需要根據(jù)負(fù)載增加集群實(shí)例，集群作為一個(gè)調(diào)度單元通過REST API對外提供服務(wù). Kubernetes的服務(wù)代理兼具了簡單的負(fù)載均衡功能，使用隨機(jī)算法把服務(wù)請求轉(zhuǎn)發(fā)到服務(wù)調(diào)度單元的其中一個(gè)實(shí)例，當(dāng)系統(tǒng)負(fù)載較高時(shí)服務(wù)代理容易成為瓶頸，可根據(jù)需要增加一個(gè)專門的負(fù)載均衡服務(wù)進(jìn)行替代. 每個(gè)服務(wù)使用私有的數(shù)據(jù)庫，上述兩個(gè)服務(wù)選用MongoDB集群. MongoDB是一個(gè)高性能、易于集群的NoSQL數(shù)據(jù)庫，部署相對簡單. 服務(wù)間通信同時(shí)使用同步及異步兩種模式. 因?yàn)楸鞠到y(tǒng)服務(wù)間沒有高頻次的通信需求，所以同步選用開發(fā)門檻低且通用性較好的REST HTTP. 評教選課與開課查詢兩個(gè)服務(wù)各自使用自己的數(shù)據(jù)庫，選課的數(shù)據(jù)是需要同步到開課查詢數(shù)據(jù)庫的，但選課數(shù)據(jù)的更新可能非常頻繁，如果實(shí)時(shí)同步的話開課查詢服務(wù)負(fù)載就會過高，所以使用異步的消息隊(duì)列來進(jìn)行緩沖，并對兩個(gè)服務(wù)進(jìn)行了解耦，當(dāng)評教選課數(shù)據(jù)更新后使用異步消息通知開課查詢服務(wù)即可. 成績錄入與成績查詢服務(wù)的設(shè)計(jì)也跟上述類似.

本系統(tǒng)沒有使用API網(wǎng)關(guān)的方式，原因是系統(tǒng)不存在大量服務(wù)間的相互調(diào)用，客戶端的移動應(yīng)用直接調(diào)用各服務(wù)模塊，并不會帶來太大的性能問題. 可以發(fā)現(xiàn)，應(yīng)用微服務(wù)架構(gòu)的教務(wù)系統(tǒng)比單體式系統(tǒng)要復(fù)雜，但好處是服務(wù)間相互隔離，系統(tǒng)某些部分可以彈性伸縮，提高了資源的利用率，而單體式系統(tǒng)只能整體遷移到性能更強(qiáng)的主機(jī)上，否則資源的爭奪就會影響系統(tǒng)所有模塊的使用.

5 結(jié)束語

本文闡述了正在興起的微服務(wù)軟件架構(gòu)原理，與傳統(tǒng)單體式應(yīng)用架構(gòu)相比，微服務(wù)能明顯降低系統(tǒng)耦合度，提高系統(tǒng)可擴(kuò)展性，增強(qiáng)系統(tǒng)持續(xù)集成能力，在大規(guī)模企業(yè)應(yīng)用中優(yōu)勢明顯. 針對微服務(wù)實(shí)踐中的服務(wù)間通信，服務(wù)發(fā)現(xiàn)和服務(wù)部署3個(gè)關(guān)鍵問題進(jìn)行了研究，提出了各場景下的解決方案并分析其優(yōu)劣，為微服務(wù)系統(tǒng)的設(shè)計(jì)提供了更多理論指引. 最后應(yīng)用具體的方案設(shè)計(jì)了基于微服務(wù)架構(gòu)的教務(wù)系統(tǒng)，提供了彈性伸縮的能力，在架構(gòu)設(shè)計(jì)層面解決了性能瓶頸問題. 后續(xù)我們將就該方案進(jìn)行具體實(shí)現(xiàn)與測試驗(yàn)證.

[1] 王磊. 微服務(wù)架構(gòu)與實(shí)踐[M]. 西安：電子工業(yè)出版社，2015.

[2]JAMES L. Micro services-Java, the Unix Way [EB/OL]. (2012-03-21) [2015-07-21]. http://2012.33degree.org/ pdf/JamesLewisMicro Services.pdf.

[3] JAMES L. Microservices [EB/OL]. (2014-03-25) [2015-08-29]. http://martinfowler.com/articles/microservices. html.

[4] O’HANLON C. A conversation with Werner Vogels [J]. Queue, 2006, 4(4): 14-22.

[5] ADRIAN C. State of the Art in Microservices [EB/OL]. (2014-12-15) [2015-04-22]. https://blog.docker.com/ 2014/12/dockercon-europe-keynote-state-of-the-art-in-microservices-by-adrian-cockcroft-battery-ventures/.

[6] EINAS H. Service-oriented architecture: scaling the uber engineering codebase as we grow [EB/OL]. (2013-10-30) [2015-07-05]. https://eng.uber.com/soa/.

[7] ADAM G. I-Tier: dismantling the monolith [EB/OL]. (2013-10-30) [2015-06-23]. https://engineering.groupon. com/2013/misc/ i-tier-dismant ling-the-monoliths/.

[8] FOWLER M, LEWIS J. Microservices [J]. Viittattu, 2014, 28: 2015.

[9] ABBOTT M L, FISHER M T. The art of scalability: scalable web architecture, processes, and organizations for the modern enterprise [M]. [S.l.]: Pearson Education, 2009.

[10] ERL T. Service-oriented architecture (SOA): concepts, technology, and design [J]. Concepts, 2005, 118(2): 33-37.

[11] SCHMIDT M T, HUTCHISON B, LAMBROS P, et al. The enterprise service bus: making service-oriented architecture real [J]. Ibm Systems Journal, 2005, 44(4): 781-797.

[12] FISH. Splitting applications or services for scale [EB/OL]. (2008-05-08) [2015-09-21]. http://akfpartners.com/ techblog/2008/05/08/sp litting-applications-or-services-for-scale.

[13]BASS L, WEBER I, ZHU Liming. DevOps: A software architect’s perspective [M]. Sydney: Addison-Wesley Professional, 2015.

[14] VILLAMIZAR M, GARCES O, CASTRO H, et al. Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud [C]//2015 10th Computing Colombian Conference, Bogota: IEEE, 2015.

[15] VIENNOT N, LECUYER M, BELL J, et al. Synapse: a microservices architecture for heterogeneous-database web applications [C]//Proceedings of the Tenth European Conference on Computer Systems. New York: ACM，2015: 21.

[16] SLEE M, AGARWAL A, KWIATKOWSKI M. Thrift: scalable cross-language services implementation [R]. [S.l]: Facebook White Paper, 2007.

[17] ONGARO D, OUSTERHOUT J. In search of an understandable consensus algorithm [C]//2014 USENIX Annual Technical Conference (USENIX ATC 14). Philadelphia: USENIX 2014: 305-319.

[18] SIMPLICITY. Service discovery overview [EB/OL]. (2015-06-10) [2015-07-22]. http://www.simplicityitself. io/getting/started/with/microservices/2015/06/10/service-discovery-overview.html.

[19] SOLTESZ S, POTZL H, FIUCZYNSKI M E, et al. Container-based operating system virtualization: a scalable, high-performance alternative to hypervisors [J]. ACM SIGOPS Operating Systems Review, 2007, 41(3): 275-287.

[20] MERKEL D. Docker: lightweight linux containers for consistent development and deployment [J]. Linux Journal, 2014(239): 2.

[21] BREWER E A. Kubernetes and the path to cloud native [C]//Proceedings of the Sixth ACM Symposium on Cloud Computing. New York: ACM, 2015: 167.

[責(zé)任編輯：韋 韜]

Research on Some Key Problems of Microservices

DENGJie-wen, CAOCai-feng

(School of Computer Science, Wuyi University, Jiangmen 529020, China)

The microservice software architecture is in the stages of exploration and rise. The successful cases of Amazon, Netflix and other Internet giants show microservices have obvious advantages in terms of large-scale enterprise applications. This paper introduces the principle of microservices architecture and analyzes its advantages and disadvantages. Some key problems encountered in the practice of microservices are discussed and some solutions are researched. In order to meet the elastic scalability requirements of general educational administration systems, a microservices-based architecture is designed. At the architecture design level it solves the performance bottleneck problems encountered in practice.

microservices; software architecture; monolithic application

1006-7302（2016）02-0049-06

TP311.1

A

2016-2-29

鄧杰文（1977—），男，廣東羅定人，碩士，講師，研究方向?yàn)檐浖軜?gòu)與軟件組件技術(shù).