鄧杰文，曹彩鳳

?

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

鄧杰文，曹彩鳳

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

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

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

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

1 微服務(wù)的定義

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

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

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

微服務(wù)的思路是把單一的巨大應(yīng)用拆分為眾多松散耦合的微小服務(wù)，其通常是按照業(yè)務(wù)功能來分解的，每一個服務(wù)雖然微小但卻實現(xiàn)相對完整的功能，使用私有的數(shù)據(jù)庫，可以單獨構(gòu)建和部署，某個服務(wù)的修改和部署不會影響其他正在運行的服務(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得以實現(xiàn)，眾多廠商也制定了相關(guān)的標準. 兩者最重要的區(qū)別在于SOA使用復(fù)雜的ESB集成為單一應(yīng)用，而微服務(wù)是輕量級的，不使用復(fù)雜的ESB，松散耦合，可以獨立部署.

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

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

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

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

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

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

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

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

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

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

3.3 服務(wù)部署問題

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

4 方案應(yīng)用

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

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

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

本系統(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)只能整體遷移到性能更強的主機上，否則資源的爭奪就會影響系統(tǒng)所有模塊的使用.

5 結(jié)束語

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

[1] 王磊. 微服務(wù)架構(gòu)與實踐[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—），男，廣東羅定人，碩士，講師，研究方向為軟件架構(gòu)與軟件組件技術(shù).