作者：huashiou
鏈接：https://segmentfault.com/a/1190000018626163

1、概述

本文以淘寶作為例子胁孙，介紹從一百個并發(fā)到千萬級并發(fā)情況下服務端的架構的演進過程唠倦，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知涮较，文章最后匯總了一些架構設計的原則稠鼻。

2、基本概念

在介紹架構之前狂票，為了避免部分讀者對架構設計中的一些概念不了解枷餐，下面對幾個最基礎的概念進行介紹。1）什么是分布式？系統(tǒng)中的多個模塊在不同服務器上部署毛肋，即可稱為分布式系統(tǒng)怨咪，如Tomcat和數(shù)據(jù)庫分別部署在不同的服務器上，或兩個相同功能的Tomcat分別部署在不同服務器上润匙。2）什么是高可用诗眨？系統(tǒng)中部分節(jié)點失效時，其他節(jié)點能夠接替它繼續(xù)提供服務孕讳，則可認為系統(tǒng)具有高可用性匠楚。3）什么是集群？一個特定領域的軟件部署在多臺服務器上并作為一個整體提供一類服務厂财，這個整體稱為集群芋簿。如Zookeeper中的Master和Slave分別部署在多臺服務器上，共同組成一個整體提供集中配置服務璃饱。在常見的集群中与斤，客戶端往往能夠連接任意一個節(jié)點獲得服務，并且當集群中一個節(jié)點掉線時荚恶，其他節(jié)點往往能夠自動的接替它繼續(xù)提供服務撩穿，這時候說明集群具有高可用性。4）什么是負載均衡谒撼？請求發(fā)送到系統(tǒng)時食寡，通過某些方式把請求均勻分發(fā)到多個節(jié)點上，使系統(tǒng)中每個節(jié)點能夠均勻的處理請求負載廓潜，則可認為系統(tǒng)是負載均衡的抵皱。5）什么是正向代理和反向代理？系統(tǒng)內(nèi)部要訪問外部網(wǎng)絡時辩蛋，統(tǒng)一通過一個代理服務器把請求轉(zhuǎn)發(fā)出去呻畸，在外部網(wǎng)絡看來就是代理服務器發(fā)起的訪問，此時代理服務器實現(xiàn)的是正向代理堪澎；當外部請求進入系統(tǒng)時擂错，代理服務器把該請求轉(zhuǎn)發(fā)到系統(tǒng)中的某臺服務器上味滞，對外部請求來說樱蛤，與之交互的只有代理服務器，此時代理服務器實現(xiàn)的是反向代理剑鞍。簡單來說昨凡，正向代理是代理服務器代替系統(tǒng)內(nèi)部來訪問外部網(wǎng)絡的過程，反向代理是外部請求訪問系統(tǒng)時通過代理服務器轉(zhuǎn)發(fā)到內(nèi)部服務器的過程蚁署。

3便脊、架構演進

3.1 單機架構

image

以淘寶作為例子：在網(wǎng)站最初時，應用數(shù)量與用戶數(shù)都較少光戈，可以把Tomcat和數(shù)據(jù)庫部署在同一臺服務器上哪痰。瀏覽器往www.taobao.com發(fā)起請求時遂赠，首先經(jīng)過DNS服務器（域名系統(tǒng)）把域名轉(zhuǎn)換為實際IP地址10.102.4.1，瀏覽器轉(zhuǎn)而訪問該IP對應的Tomcat晌杰。架構瓶頸：隨著用戶數(shù)的增長跷睦，Tomcat和數(shù)據(jù)庫之間競爭資源，單機性能不足以支撐業(yè)務肋演。

3.2第一次演進：Tomcat與數(shù)據(jù)庫分開部署

image

Tomcat和數(shù)據(jù)庫分別獨占服務器資源抑诸，顯著提高兩者各自性能。架構瓶頸：隨著用戶數(shù)的增長爹殊，并發(fā)讀寫數(shù)據(jù)庫成為瓶頸蜕乡。Tips：歡迎關注微信公眾號：Java后端，獲取更多技術博文推送梗夸。

3.3 第二次演進：引入本地緩存和分布式緩存

image

在Tomcat同服務器上或同JVM中增加本地緩存层玲，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html頁面等绒瘦。通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉称簿，大大降低數(shù)據(jù)庫壓力。其中涉及的技術包括：使用memcached作為本地緩存惰帽，使用Redis作為分布式緩存憨降，還會涉及緩存一致性、緩存穿透/擊穿该酗、緩存雪崩授药、熱點數(shù)據(jù)集中失效等問題。架構瓶頸：緩存抗住了大部分的訪問請求呜魄，隨著用戶數(shù)的增長悔叽，并發(fā)壓力主要落在單機的Tomcat上，響應逐漸變慢爵嗅。

3.4 第三次演進：引入反向代理實現(xiàn)負載均衡

image

在多臺服務器上分別部署Tomcat娇澎，使用反向代理軟件（Nginx）把請求均勻分發(fā)到每個Tomcat中。此處假設Tomcat最多支持100個并發(fā)睹晒，Nginx最多支持50000個并發(fā)趟庄，那么理論上Nginx把請求分發(fā)到500個Tomcat上，就能抗住50000個并發(fā)伪很。其中涉及的技術包括：Nginx戚啥、HAProxy，兩者都是工作在網(wǎng)絡第七層的反向代理軟件锉试，主要支持http協(xié)議猫十，還會涉及session共享、文件上傳下載的問題。架構瓶頸：反向代理使應用服務器可支持的并發(fā)量大大增加拖云，但并發(fā)量的增長也意味著更多請求穿透到數(shù)據(jù)庫贷笛，單機的數(shù)據(jù)庫最終成為瓶頸。

3.5 第四次演進：數(shù)據(jù)庫讀寫分離

image

把數(shù)據(jù)庫劃分為讀庫和寫庫宙项，讀庫可以有多個昨忆，通過同步機制把寫庫的數(shù)據(jù)同步到讀庫，對于需要查詢最新寫入數(shù)據(jù)場景杉允，可通過在緩存中多寫一份邑贴，通過緩存獲得最新數(shù)據(jù)。其中涉及的技術包括：Mycat叔磷，它是數(shù)據(jù)庫中間件拢驾，可通過它來組織數(shù)據(jù)庫的分離讀寫和分庫分表，客戶端通過它來訪問下層數(shù)據(jù)庫改基，還會涉及數(shù)據(jù)同步繁疤，數(shù)據(jù)一致性的問題。架構瓶頸：業(yè)務逐漸變多秕狰，不同業(yè)務之間的訪問量差距較大稠腊，不同業(yè)務直接競爭數(shù)據(jù)庫，相互影響性能鸣哀。

3.6 第五次演進：數(shù)據(jù)庫按業(yè)務分庫

image

把不同業(yè)務的數(shù)據(jù)保存到不同的數(shù)據(jù)庫中架忌，使業(yè)務之間的資源競爭降低，對于訪問量大的業(yè)務我衬，可以部署更多的服務器來支撐叹放。這樣同時導致跨業(yè)務的表無法直接做關聯(lián)分析，需要通過其他途徑來解決挠羔，但這不是本文討論的重點井仰，有興趣的可以自行搜索解決方案。架構瓶頸：隨著用戶數(shù)的增長破加，單機的寫庫會逐漸會達到性能瓶頸俱恶。

3.7 第六次演進：把大表拆分為小表

image

比如針對評論數(shù)據(jù)，可按照商品ID進行hash范舀，路由到對應的表中存儲合是；針對支付記錄，可按照小時創(chuàng)建表尿背，每個小時表繼續(xù)拆分為小表端仰，使用用戶ID或記錄編號來路由數(shù)據(jù)捶惜。只要實時操作的表數(shù)據(jù)量足夠小田藐，請求能夠足夠均勻的分發(fā)到多臺服務器上的小表，那數(shù)據(jù)庫就能通過水平擴展的方式來提高性能。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問控制汽久。這種做法顯著的增加了數(shù)據(jù)庫運維的難度鹤竭，對DBA的要求較高。數(shù)據(jù)庫設計到這種結構時景醇，已經(jīng)可以稱為分布式數(shù)據(jù)庫但這只是一個邏輯的數(shù)據(jù)庫整體臀稚，數(shù)據(jù)庫里不同的組成部分是由不同的組件單獨來實現(xiàn)的如分庫分表的管理和請求分發(fā)，由Mycat實現(xiàn)三痰，SQL的解析由單機的數(shù)據(jù)庫實現(xiàn)吧寺，讀寫分離可能由網(wǎng)關和消息隊列來實現(xiàn)，查詢結果的匯總可能由數(shù)據(jù)庫接口層來實現(xiàn)等等這種架構其實是MPP（大規(guī)模并行處理）架構的一類實現(xiàn)散劫。目前開源和商用都已經(jīng)有不少MPP數(shù)據(jù)庫稚机，開源中比較流行的有Greenplum、TiDB获搏、Postgresql XC赖条、HAWQ等，商用的如南大通用的GBase常熙、睿帆科技的雪球DB纬乍、華為的LibrA等等不同的MPP數(shù)據(jù)庫的側重點也不一樣，如TiDB更側重于分布式OLTP場景裸卫，Greenplum更側重于分布式OLAP場景這些MPP數(shù)據(jù)庫基本都提供了類似Postgresql仿贬、Oracle、MySQL那樣的SQL標準支持能力墓贿，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機器上并行執(zhí)行诅蝶，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進行返回也提供了諸如權限管理、分庫分表募壕、事務调炬、數(shù)據(jù)副本等能力，并且大多能夠支持100個節(jié)點以上的集群舱馅，大大降低了數(shù)據(jù)庫運維的成本缰泡，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴展。架構瓶頸：數(shù)據(jù)庫和Tomcat都能夠水平擴展代嗤，可支撐的并發(fā)大幅提高棘钞，隨著用戶數(shù)的增長，最終單機的Nginx會成為瓶頸干毅。

3.8 第七次演進：使用LVS或F5來使多個Nginx負載均衡

image

由于瓶頸在Nginx宜猜，因此無法通過兩層的Nginx來實現(xiàn)多個Nginx的負載均衡。圖中的LVS和F5是工作在網(wǎng)絡第四層的負載均衡解決方案硝逢，其中LVS是軟件姨拥，運行在操作系統(tǒng)內(nèi)核態(tài)绅喉，可對TCP請求或更高層級的網(wǎng)絡協(xié)議進行轉(zhuǎn)發(fā)，因此支持的協(xié)議更豐富叫乌，并且性能也遠高于Nginx柴罐，可假設單機的LVS可支持幾十萬個并發(fā)的請求轉(zhuǎn)發(fā)；F5是一種負載均衡硬件憨奸，與LVS提供的能力類似革屠，性能比LVS更高，但價格昂貴排宰。由于LVS是單機版的軟件似芝，若LVS所在服務器宕機則會導致整個后端系統(tǒng)都無法訪問，因此需要有備用節(jié)點板甘」酰可使用keepalived軟件模擬出虛擬IP，然后把虛擬IP綁定到多臺LVS服務器上虾啦，瀏覽器訪問虛擬IP時麻诀，會被路由器重定向到真實的LVS服務器當主LVS服務器宕機時，keepalived軟件會自動更新路由器中的路由表傲醉，把虛擬IP重定向到另外一臺正常的LVS服務器蝇闭，從而達到LVS服務器高可用的效果。此處需要注意的是硬毕，上圖中從Nginx層到Tomcat層這樣畫并不代表全部Nginx都轉(zhuǎn)發(fā)請求到全部的Tomcat在實際使用時呻引，可能會是幾個Nginx下面接一部分的Tomcat，這些Nginx之間通過keepalived實現(xiàn)高可用吐咳，其他的Nginx接另外的Tomcat逻悠，這樣可接入的Tomcat數(shù)量就能成倍的增加。架構瓶頸：由于LVS也是單機的韭脊，隨著并發(fā)數(shù)增長到幾十萬時童谒，LVS服務器最終會達到瓶頸，此時用戶數(shù)達到千萬甚至上億級別沪羔，用戶分布在不同的地區(qū)饥伊，與服務器機房距離不同，導致了訪問的延遲會明顯不同蔫饰。

3.9 第八次演進：通過DNS輪詢實現(xiàn)機房間的負載均衡

image

在DNS服務器中可配置一個域名對應多個IP地址琅豆，每個IP地址對應到不同的機房里的虛擬IP。當用戶訪問www.taobao.com時篓吁，DNS服務器會使用輪詢策略或其他策略茫因，來選擇某個IP供用戶訪問。此方式能實現(xiàn)機房間的負載均衡至此杖剪，系統(tǒng)可做到機房級別的水平擴展冻押，千萬級到億級的并發(fā)量都可通過增加機房來解決驰贷，系統(tǒng)入口處的請求并發(fā)量不再是問題。架構瓶頸：隨著數(shù)據(jù)的豐富程度和業(yè)務的發(fā)展翼雀，檢索、分析等需求越來越豐富孩擂，單單依靠數(shù)據(jù)庫無法解決如此豐富的需求狼渊。

3.10 第九次演進：引入NoSQL數(shù)據(jù)庫和搜索引擎等技術

image

當數(shù)據(jù)庫中的數(shù)據(jù)多到一定規(guī)模時，數(shù)據(jù)庫就不適用于復雜的查詢了类垦，往往只能滿足普通查詢的場景狈邑。對于統(tǒng)計報表場景，在數(shù)據(jù)量大時不一定能跑出結果蚤认，而且在跑復雜查詢時會導致其他查詢變慢對于全文檢索米苹、可變數(shù)據(jù)結構等場景，數(shù)據(jù)庫天生不適用砰琢。因此需要針對特定的場景蘸嘶，引入合適的解決方案。如對于海量文件存儲陪汽，可通過分布式文件系統(tǒng)HDFS解決训唱，對于key value類型的數(shù)據(jù)，可通過HBase和Redis等方案解決對于全文檢索場景挚冤，可通過搜索引擎如ElasticSearch解決况增，對于多維分析場景，可通過Kylin或Druid等方案解決训挡。當然澳骤，引入更多組件同時會提高系統(tǒng)的復雜度，不同的組件保存的數(shù)據(jù)需要同步澜薄，需要考慮一致性的問題为肮，需要有更多的運維手段來管理這些組件等。架構瓶頸：引入更多組件解決了豐富的需求肤京，業(yè)務維度能夠極大擴充弥锄，隨之而來的是一個應用中包含了太多的業(yè)務代碼，業(yè)務的升級迭代變得困難蟆沫。

3.11 第十次演進：大應用拆分為小應用

image

按照業(yè)務板塊來劃分應用代碼籽暇，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代饭庞。這時候應用之間可能會涉及到一些公共配置戒悠，可以通過分布式配置中心Zookeeper來解決。架構瓶頸：不同應用之間存在共用的模塊舟山，由應用單獨管理會導致相同代碼存在多份绸狐，導致公共功能升級時全部應用代碼都要跟著升級卤恳。

3.12 第十一次演進：復用的功能抽離成微服務

image

如用戶管理、訂單寒矿、支付突琳、鑒權等功能在多個應用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理這樣的服務就是所謂的微服務符相，應用和服務之間通過HTTP拆融、TCP或RPC請求等多種方式來訪問公共服務，每個單獨的服務都可以由單獨的團隊來管理啊终。此外镜豹，可以通過Dubbo、SpringCloud等框架實現(xiàn)服務治理蓝牲、限流趟脂、熔斷、降級等功能例衍，提高服務的穩(wěn)定性和可用性昔期。架構瓶頸：不同服務的接口訪問方式不同，應用代碼需要適配多種訪問方式才能使用服務佛玄，此外镇眷，應用訪問服務，服務之間也可能相互訪問翎嫡，調(diào)用鏈將會變得非常復雜欠动，邏輯變得混亂。

3.13 第十二次演進：引入企業(yè)服務總線ESB屏蔽服務接口的訪問差異

image

通過ESB統(tǒng)一進行訪問協(xié)議轉(zhuǎn)換惑申，應用統(tǒng)一通過ESB來訪問后端服務具伍，服務與服務之間也通過ESB來相互調(diào)用，以此降低系統(tǒng)的耦合程度圈驼。這種單個應用拆分為多個應用人芽，公共服務單獨抽取出來來管理，并使用企業(yè)消息總線來解除服務之間耦合問題的架構绩脆，就是所謂的SOA（面向服務）架構萤厅，這種架構與微服務架構容易混淆，因為表現(xiàn)形式十分相似靴迫。個人理解惕味，微服務架構更多是指把系統(tǒng)里的公共服務抽取出來單獨運維管理的思想，而SOA架構則是指一種拆分服務并使服務接口訪問變得統(tǒng)一的架構思想玉锌，SOA架構中包含了微服務的思想名挥。架構瓶頸：業(yè)務不斷發(fā)展，應用和服務都會不斷變多主守，應用和服務的部署變得復雜禀倔，同一臺服務器上部署多個服務還要解決運行環(huán)境沖突的問題此外榄融，對于如大促這類需要動態(tài)擴縮容的場景，需要水平擴展服務的性能救湖，就需要在新增的服務上準備運行環(huán)境愧杯，部署服務等，運維將變得十分困難鞋既。

3.14 第十三次演進：****引入容器化技術實現(xiàn)運行環(huán)境隔離與動態(tài)服務管理

image

目前最流行的容器化技術是Docker力九，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像涛救，通過K8S來動態(tài)分發(fā)和部署鏡像畏邢。Docker鏡像可理解為一個能運行你的應用/服務的最小的操作系統(tǒng)业扒，里面放著應用/服務的運行代碼检吆，運行環(huán)境根據(jù)實際的需要設置好。把整個“操作系統(tǒng)”打包為一個鏡像后程储，就可以分發(fā)到需要部署相關服務的機器上蹭沛，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單章鲤。在大促的之前摊灭，可以在現(xiàn)有的機器集群上劃分出服務器來啟動Docker鏡像，增強服務的性能大促過后就可以關閉鏡像败徊，對機器上的其他服務不造成影響（在第18節(jié)之前帚呼，服務運行在新增機器上需要修改系統(tǒng)配置來適配服務，這會導致機器上其他服務需要的運行環(huán)境被破壞）皱蹦。架構瓶頸：使用容器化技術后服務動態(tài)擴縮容問題得以解決煤杀，但是機器還是需要公司自身來管理，在非大促的時候沪哺，還是需要閑置著大量的機器資源來應對大促沈自，機器自身成本和運維成本都極高，資源利用率低辜妓。

3.15 第十四次演進：以云平臺承載系統(tǒng)

image

系統(tǒng)可部署到公有云上枯途，利用公有云的海量機器資源，解決動態(tài)硬件資源的問題在大促的時間段里籍滴，在云平臺中臨時申請更多的資源酪夷，結合Docker和K8S來快速部署服務，在大促結束后釋放資源孽惰，真正做到按需付費捶索，資源利用率大大提高，同時大大降低了運維成本灰瞻。所謂的云平臺腥例，就是把海量機器資源辅甥，通過統(tǒng)一的資源管理，抽象為一個資源整體在云平臺上可按需動態(tài)申請硬件資源（如CPU燎竖、內(nèi)存璃弄、網(wǎng)絡等），并且之上提供通用的操作系統(tǒng)构回，提供常用的技術組件（如Hadoop技術棧夏块，MPP數(shù)據(jù)庫等）供用戶使用，甚至提供開發(fā)好的應用用戶不需要關心應用內(nèi)部使用了什么技術纤掸，就能夠解決需求（如音視頻轉(zhuǎn)碼服務脐供、郵件服務、個人博客等）借跪。在云平臺中會涉及如下幾個概念：

1. IaaS：基礎設施即服務政己。對應于上面所說的機器資源統(tǒng)一為資源整體，可動態(tài)申請硬件資源的層面掏愁；

2. PaaS：平臺即服務歇由。對應于上面所說的提供常用的技術組件方便系統(tǒng)的開發(fā)和維護；

3. SaaS：軟件即服務果港。對應于上面所說的提供開發(fā)好的應用或服務沦泌，按功能或性能要求付費。

至此：以上所提到的從高并發(fā)訪問問題辛掠，到服務的架構和系統(tǒng)實施的層面都有了各自的解決方案谢谦。但同時也應該意識到，在上面的介紹中萝衩，其實是有意忽略了諸如跨機房數(shù)據(jù)同步回挽、分布式事務實現(xiàn)等等的實際問題，這些問題以后有機會再拿出來單獨討論欠气。

4厅各、架構設計總結

1）架構的調(diào)整是否必須按照上述演變路徑進行？不是的预柒，以上所說的架構演變順序只是針對某個側面進行單獨的改進在實際場景中队塘，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面宜鸯，這時候就應該按照實際問題實際解決憔古。如在政府類的并發(fā)量可能不大，但業(yè)務可能很豐富的場景淋袖，高并發(fā)就不是重點解決的問題鸿市，此時優(yōu)先需要的可能會是豐富需求的解決方案。2）對于將要實施的系統(tǒng)，架構應該設計到什么程度焰情？對于單次實施并且性能指標明確的系統(tǒng)林说，架構設計到能夠支持系統(tǒng)的性能指標要求就足夠了税课，但要留有擴展架構的接口以便不備之需。對于不斷發(fā)展的系統(tǒng)，如電商平臺暇韧，應設計到能滿足下一階段用戶量和性能指標要求的程度奥额，并根據(jù)業(yè)務的增長不斷的迭代升級架構借卧，以支持更高的并發(fā)和更豐富的業(yè)務泄隔。3）服務端架構和大數(shù)據(jù)架構有什么區(qū)別？所謂的“大數(shù)據(jù)”其實是海量數(shù)據(jù)采集清洗轉(zhuǎn)換耕蝉、數(shù)據(jù)存儲崔梗、數(shù)據(jù)分析、數(shù)據(jù)服務等場景解決方案的一個統(tǒng)稱垒在，在每一個場景都包含了多種可選的技術如數(shù)據(jù)采集有Flume蒜魄、Sqoop、Kettle等爪膊，數(shù)據(jù)存儲有分布式文件系統(tǒng)HDFS权悟、FastDFS砸王，NoSQL數(shù)據(jù)庫HBase推盛、MongoDB等，數(shù)據(jù)分析有Spark技術棧谦铃、機器學習算法等耘成。總的來說大數(shù)據(jù)架構就是根據(jù)業(yè)務的需求驹闰，整合各種大數(shù)據(jù)組件組合而成的架構瘪菌，一般會提供分布式存儲、分布式計算嘹朗、多維分析师妙、數(shù)據(jù)倉庫、機器學習算法等能力屹培。而服務端架構更多指的是應用組織層面的架構默穴，底層能力往往是由大數(shù)據(jù)架構來提供。4）有沒有一些架構設計的原則褪秀？

• N+1設計：系統(tǒng)中的每個組件都應做到?jīng)]有單點故障蓄诽；

• 回滾設計：確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應能有辦法回滾版本媒吗；

• 禁用設計：應該提供控制具體功能是否可用的配置仑氛，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能；

• 監(jiān)控設計：在設計階段就要考慮監(jiān)控的手段；

• 多活數(shù)據(jù)中心設計：若系統(tǒng)需要極高的高可用锯岖，應考慮在多地實施數(shù)據(jù)中心進行多活介袜，至少在一個機房斷電的情況下系統(tǒng)依然可用；

• 采用成熟的技術：剛開發(fā)的或開源的技術往往存在很多隱藏的bug出吹，出了問題沒有商業(yè)支持可能會是一個災難米酬；

• 資源隔離設計：應避免單一業(yè)務占用全部資源；

• 架構應能水平擴展：系統(tǒng)只有做到能水平擴展趋箩，才能有效避免瓶頸問題赃额；

• 非核心則購買：非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購買成熟的產(chǎn)品叫确；

• 使用商用硬件：商用硬件能有效降低硬件故障的機率跳芳；

• 快速迭代：系統(tǒng)應該快速開發(fā)小功能模塊，盡快上線進行驗證竹勉，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風險飞盆；

• 無狀態(tài)設計：服務接口應該做成無狀態(tài)的，當前接口的訪問不依賴于接口上次訪問的狀態(tài)次乓。