摘要：應(yīng)用的研發(fā)上線(xiàn)運(yùn)維運(yùn)營(yíng)形成閉環(huán)，順利完成從對(duì)內(nèi)服務(wù)到公共平臺(tái)的升級(jí)。從功能角度，只能支持靜態(tài)方式設(shè)置反向代理，然后，而平臺(tái)有服務(wù)對(duì)應(yīng)的后端服務(wù)和端口是有動(dòng)態(tài)調(diào)整需求。架構(gòu)上是基礎(chǔ)組件需要進(jìn)行升級(jí)，數(shù)據(jù)訪(fǎng)問(wèn)層日志監(jiān)控系統(tǒng)等。

? ? ? ?MaxLeap早期是一家研發(fā)、運(yùn)營(yíng)移動(dòng)應(yīng)用和手機(jī)游戲公司，發(fā)展過(guò)程中積累了很多通用組件。這些組件很大程度幫公司在移動(dòng)研發(fā)過(guò)程中節(jié)省了時(shí)間和成本，有沒(méi)有可能以云服務(wù)的方式開(kāi)放出去，創(chuàng)造更大的價(jià)值？延續(xù)這個(gè)思路，公司成立了云服務(wù)部門(mén)，嘗試服務(wù)的商業(yè)化。

? ? ? ?從對(duì)內(nèi)提供接口服務(wù)到對(duì)外提供云服務(wù)，經(jīng)歷了三個(gè)階段發(fā)展：1.0時(shí)代，定位對(duì)內(nèi)服務(wù)，為公司研發(fā)的幾十款應(yīng)用提供服務(wù)端功能，推送、統(tǒng)一用戶(hù)管理等API接口，可以說(shuō)是非常普通的接口服務(wù)；2.0時(shí)代，定位對(duì)外服務(wù)，除了支撐公司的移動(dòng)研發(fā)以外，同時(shí)對(duì)外開(kāi)放服務(wù)，提供更多的功能接口，也參考了行業(yè)的通用做法，形成了針對(duì)移動(dòng)研發(fā)加速和提高運(yùn)營(yíng)效率的BaaS云平臺(tái)；3.0時(shí)代，定位基礎(chǔ)研發(fā)平臺(tái)，工具鏈逐漸完整，從研發(fā)、上線(xiàn)、運(yùn)維到運(yùn)營(yíng)，提供應(yīng)用管理、支付、IM、推送等SaaS功能，也提供托管、發(fā)布、監(jiān)控、日志等PaaS功能，逐步形成SaaS + PaaS的研發(fā)平臺(tái)。

? ? ? ?常見(jiàn)的云服務(wù)有幾種方式。

? ? ? ?IaaS（Infrastructure as a Service），基礎(chǔ)設(shè)施即服務(wù)。提供云端的基礎(chǔ)設(shè)施為主，比如提供主機(jī)、存儲(chǔ)、網(wǎng)絡(luò)、CDN、域名解析等功能，知名廠商有阿里云、AWS、Azure等。

? ? ? ?PaaS（Platform），平臺(tái)即服務(wù)。提供云端的發(fā)布、數(shù)據(jù)庫(kù)服務(wù)、文件存儲(chǔ)、緩存服務(wù)、容器管理等基礎(chǔ)存儲(chǔ)和管理組件，自動(dòng)化了程序的配置、發(fā)布、管理–Heroku、Google App Engine、Force.com等。

? ? ? ?SaaS（Software as a Service），軟件即服務(wù)。提供云端的應(yīng)用服務(wù)，ERP、HR、CRM等在線(xiàn)系統(tǒng)，每個(gè)賬戶(hù)或者每家公司有獨(dú)立的數(shù)據(jù)存儲(chǔ)，通過(guò)賬戶(hù)進(jìn)行權(quán)限和訪(fǎng)問(wèn)隔離，知名廠商有Salesforce、Successfactor、Zendesk等。

? ? ? ?BaaS（Backen as a Service），后端即服務(wù)，起初專(zhuān)指針對(duì)移動(dòng)端的研發(fā)提供的云服務(wù)，降低移動(dòng)研發(fā)的復(fù)雜度，讓開(kāi)發(fā)者關(guān)注與移動(dòng)端開(kāi)發(fā)即可。流行的服務(wù)有幾大類(lèi)：綜合類(lèi)，Parse、Kinvey；分析類(lèi)，友盟、TalkingData、神策數(shù)據(jù)；支付類(lèi)，Beecloud、Ping++；IM類(lèi)，環(huán)信、網(wǎng)易；消息類(lèi)，極光、個(gè)推等。

? ? ? ?我們?cè)?.0時(shí)代把自己定位于BaaS，隨著功能的不斷演進(jìn)3.0著眼于PaaS和SaaS。

? ? ? ?當(dāng)時(shí)公司有幾十款A(yù)pp需要研發(fā)和運(yùn)營(yíng)，每個(gè)應(yīng)用功能各異，種類(lèi)包括瀏覽器、音視頻工具、社交工具、清理大師、圖片存儲(chǔ)類(lèi)和手游等，門(mén)類(lèi)很多、很雜。如何提高研發(fā)效率，實(shí)現(xiàn)一套統(tǒng)一的研發(fā)、管理和運(yùn)營(yíng)體系，是當(dāng)時(shí)的主要訴求。對(duì)主要功能進(jìn)行梳理之后發(fā)現(xiàn)，各類(lèi)應(yīng)用共同需要依賴(lài)的組件包括，用戶(hù)體系、云參數(shù)體系、推送服務(wù)、數(shù)據(jù)存儲(chǔ)和廣告服務(wù)。

圖1 1.0業(yè)務(wù)模型

? ? ? ?需求基本明確了，目標(biāo)是快速上線(xiàn)，然后小版本迭代。

? ? ? ?當(dāng)時(shí)4個(gè)后端研發(fā)人員，Java出身，人少但是技術(shù)精干。結(jié)合團(tuán)隊(duì)情況和產(chǎn)品需求，決定采用如下架構(gòu)，簡(jiǎn)單但給力。

圖2 1.0架構(gòu)

? ? ? ?典型的web應(yīng)用架構(gòu)方式，使用Nginx做反向代理和負(fù)載均衡，后面跟了多個(gè)JVM實(shí)例。每個(gè)JVM實(shí)例由Jetty作為應(yīng)用服務(wù)器，提供REST接口，服務(wù)層實(shí)現(xiàn)具體的邏輯。DAL層對(duì)DB和緩存進(jìn)行封裝，提供統(tǒng)一的數(shù)據(jù)訪(fǎng)問(wèn)接口。Redis作為緩存方案，支持多個(gè)shard水平擴(kuò)容，TPS高、性能好。Cassandra作為數(shù)據(jù)存儲(chǔ)引擎，無(wú)中心、可水平擴(kuò)展、易維護(hù)，沒(méi)有專(zhuān)門(mén)的運(yùn)維人員，對(duì)研發(fā)人員非常友好，由于沒(méi)有事務(wù)場(chǎng)景，NoSQL完全滿(mǎn)足當(dāng)時(shí)的需求。RabbitMQ作為消息中間件方案，不同進(jìn)程間通信，支持HA，支持持久化。Zookeeper用于存儲(chǔ)基礎(chǔ)配置信息。

? ? ? ?這種簡(jiǎn)單的設(shè)計(jì)，有效支持了公司幾十款應(yīng)用的運(yùn)行，日訪(fǎng)問(wèn)量達(dá)數(shù)十億級(jí)別。統(tǒng)一后臺(tái)基礎(chǔ)服務(wù)和移動(dòng)端SDK后，提高了移動(dòng)應(yīng)用的研發(fā)和上線(xiàn)速度，研發(fā)了用戶(hù)管理、推送這些基礎(chǔ)功能，在移動(dòng)端幾行代碼搞定。通過(guò)控制臺(tái)，能有效管理應(yīng)用和配置信息。其實(shí)對(duì)于多數(shù)十多個(gè)研發(fā)人員的公司來(lái)講，這樣的單應(yīng)用架構(gòu)性?xún)r(jià)比最高，解決商業(yè)上的問(wèn)題才是關(guān)鍵。

? ? ? ?也有不少需要改進(jìn)的地方，Cassandra作為業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)，查詢(xún)非常不靈活，依賴(lài)設(shè)計(jì)時(shí)對(duì)row key和composit key的精確把握，擴(kuò)展非常困難，再加上對(duì)翻頁(yè)、排序等支持有限，在數(shù)據(jù)層做了很多特殊處理。整個(gè)系統(tǒng)沒(méi)有脫單，Redis、Nginx還有單點(diǎn)問(wèn)題，脫單是高可用系統(tǒng)中首要需要解決的問(wèn)題。所有服務(wù)部署在一起，出問(wèn)題時(shí)相互影響，項(xiàng)目耦合度高，擴(kuò)展困難。開(kāi)發(fā)效率低，發(fā)布新功能時(shí)相互依賴(lài)等，這些都是單用架構(gòu)設(shè)計(jì)最明顯的問(wèn)題。

? ? ? ?隨著業(yè)務(wù)不斷發(fā)展以及新的產(chǎn)品定位，單應(yīng)用架構(gòu)的弊端不斷暴露出來(lái)，要求我們?cè)谛碌囊?guī)劃中，重新設(shè)計(jì)整個(gè)后端架構(gòu)。

? ? ? ?來(lái)看新的需求：

定位公有云，服務(wù)標(biāo)準(zhǔn)化

多租戶(hù)支持，用戶(hù)數(shù)據(jù)需要隔離，每個(gè)公司都有自己的后臺(tái)管理和賬號(hào)管理，不同工作人員區(qū)分權(quán)限職責(zé)，允許同時(shí)有多款應(yīng)用，應(yīng)用在邏輯上相互獨(dú)立，每個(gè)應(yīng)用可以使用所有服務(wù)

更靈活的存儲(chǔ)和查詢(xún)服務(wù)

提供基礎(chǔ)數(shù)據(jù)分析功能，提供代碼托管等更多云服務(wù)

圖3 2.0業(yè)務(wù)模型

? ? ? ?服務(wù)規(guī)模擴(kuò)大后，大家解決單應(yīng)用弊端的方法也都類(lèi)似，以獨(dú)立運(yùn)行的業(yè)務(wù)為單位，對(duì)服務(wù)縱向拆分，提高單個(gè)服務(wù)的聚合程度，降低服務(wù)間的相互依賴(lài)，從而解決降低研發(fā)、測(cè)試、上線(xiàn)過(guò)程中各個(gè)服務(wù)相互依賴(lài)、相互影響的問(wèn)題。

? ? ? ?除此以外，我們對(duì)數(shù)據(jù)存儲(chǔ)和網(wǎng)絡(luò)層也進(jìn)行了改進(jìn)。平臺(tái)所支持的兩類(lèi)服務(wù)，分別是云服務(wù)和云計(jì)算。在新的設(shè)計(jì)中，云服務(wù)部分的重點(diǎn)是重構(gòu)、支持在新架構(gòu)上快速研發(fā)新服務(wù)，云計(jì)算部分的重點(diǎn)是，構(gòu)建起來(lái)一個(gè)穩(wěn)定、可靠、高效的基礎(chǔ)架構(gòu)。

圖4 2.0云服務(wù)架構(gòu)

? ? ? ?網(wǎng)絡(luò)，最外層增加了ELB，IP地址直接暴露在公網(wǎng)是非常危險(xiǎn)的方式，通過(guò)DNS配置CNAME指向域名，降低了被DDOS的風(fēng)險(xiǎn)，提高了Nginx的可用性。ELB本身會(huì)在訪(fǎng)問(wèn)增加時(shí)，自動(dòng)伸縮，配合IaaS廠商提供的AutoScalling服務(wù)，可以抵御多數(shù)DDOS攻擊。通過(guò)Nginx作為反向代理和負(fù)載均衡，不同服務(wù)指向不同的upstram地址和端口。服務(wù)間禁止相互依賴(lài)。

? ? ? ?容器，每個(gè)服務(wù)都運(yùn)行在Docker中，服務(wù)之間環(huán)境和資源隔離，能夠快速遷移和部署，統(tǒng)一了交付和發(fā)布流程。每個(gè)容器無(wú)狀態(tài)，服務(wù)遷移、擴(kuò)容、宕機(jī)等問(wèn)題迎刃而解，在服務(wù)化過(guò)程中起到很關(guān)鍵的作用。

? ? ? ?數(shù)據(jù)，NoSQL部分主要依賴(lài)MongoDB，Wired Tiger + SSD，由于MongoDB的Schema-less特性，開(kāi)發(fā)者可以根據(jù)自己的需求隨時(shí)調(diào)整實(shí)體的定義。天生為分布式設(shè)計(jì)，支持復(fù)制集高可用方案，支持多Shard水平擴(kuò)展。關(guān)系型數(shù)據(jù)庫(kù)采用MySQL，用于實(shí)現(xiàn)支付、訂單、配置信息等需要事務(wù)支持的業(yè)務(wù)，我們基于MHA實(shí)現(xiàn)MySQL的高可用和讀寫(xiě)分離。不同服務(wù)所依賴(lài)的庫(kù)必須分離，從數(shù)據(jù)著手保障用戶(hù)資源的隔離。

? ? ? ?存儲(chǔ)/緩存，塊數(shù)據(jù)依賴(lài)AWS的S3，權(quán)限控制、分桶策略比較實(shí)用，可用性有保障；緩存依然使用Redis，為了解決單點(diǎn)問(wèn)題，對(duì)原有版本進(jìn)行了升級(jí)，采用官方的3.0集群方案，支持分片和高可用，當(dāng)然也有其它方案可選，比如codis等代理的方案。

圖5 2.0云分析架構(gòu)

? ? ? ?數(shù)據(jù)收集部分采用REST + Kafka方式，其中很重要的一部分是DataTransform，用于數(shù)據(jù)標(biāo)準(zhǔn)化、過(guò)濾、流控等用途，基于vert.x實(shí)現(xiàn)。

? ? ? ?計(jì)算部分參考Lambda架構(gòu)實(shí)現(xiàn)，分為Speed Layer、Batch Layer、Serving Layer三層。

? ? ? ?Speed Layer，基于Storm實(shí)現(xiàn)，引擎監(jiān)聽(tīng)Kafka中收集到的新數(shù)據(jù)，把一些對(duì)實(shí)時(shí)性要求高的指標(biāo)計(jì)算完成，寫(xiě)入展示層。Batch Layer，基于Hadoop生態(tài)實(shí)現(xiàn)，通過(guò)開(kāi)源項(xiàng)目Camus，把Kafka中監(jiān)聽(tīng)到的數(shù)據(jù)存儲(chǔ)在HDFS中，然后通過(guò)HIVE或者M(jìn)/R的Job，計(jì)算各種指標(biāo)，工作流通過(guò)oozie來(lái)調(diào)度，最終結(jié)果也寫(xiě)入展示層，并且覆蓋掉實(shí)時(shí)計(jì)算的結(jié)果。結(jié)果數(shù)據(jù)根據(jù)不同指標(biāo)，按天、周、月分別存儲(chǔ)在Cassandra中，有很高的寫(xiě)速度，無(wú)限水平擴(kuò)展。展示層，數(shù)據(jù)同時(shí)用antlr4j實(shí)現(xiàn)了SQL解析，訪(fǎng)問(wèn)Cassandra中的計(jì)算結(jié)果。

? ? ? ?相比較1.0時(shí)期，架構(gòu)上更合理，擴(kuò)展性、維護(hù)性、魯棒性都有很明顯提升。功能上，完成移動(dòng)應(yīng)用研發(fā)大部分組件（統(tǒng)計(jì)分析、支付、IM、社交、在線(xiàn)參數(shù)、推送、營(yíng)銷(xiāo)、云數(shù)據(jù)、云存儲(chǔ)、云代碼)。應(yīng)用的研發(fā)、上線(xiàn)、運(yùn)維、運(yùn)營(yíng)形成閉環(huán)，順利完成從對(duì)內(nèi)服務(wù)到公共BaaS平臺(tái)的升級(jí)。團(tuán)隊(duì)上，1-3人一個(gè)服務(wù)的研發(fā)，測(cè)試、上線(xiàn)的節(jié)奏可以自己把控。

? ? ? ?當(dāng)然，業(yè)務(wù)在演進(jìn)，也有新的問(wèn)題需要去解決。從功能角度，Nginx只能支持靜態(tài)方式設(shè)置反向代理，然后reload，而平臺(tái)有服務(wù)對(duì)應(yīng)的后端服務(wù)和端口是有動(dòng)態(tài)調(diào)整需求。從架構(gòu)角度，在相對(duì)成熟的系統(tǒng)中，日志、監(jiān)控這些基礎(chǔ)組件需要統(tǒng)一收集、管理、處理。數(shù)據(jù)訪(fǎng)問(wèn)層、RPC等基礎(chǔ)服務(wù)也要標(biāo)準(zhǔn)化。

圖6 3.0業(yè)務(wù)模型

? ? ? ?對(duì)于創(chuàng)業(yè)公司而言，業(yè)務(wù)隨時(shí)會(huì)有調(diào)整，作為技術(shù)人員，需要能夠應(yīng)對(duì)這種變化，架構(gòu)上為這些變化做準(zhǔn)備。產(chǎn)品向3.0演進(jìn)由新的業(yè)務(wù)需求和架構(gòu)自身的調(diào)整需求共同推動(dòng)。新的業(yè)務(wù)需要支撐一個(gè)全網(wǎng)營(yíng)銷(xiāo)的SaaS產(chǎn)品線(xiàn)，產(chǎn)品支持配置操作生成App + 微信商城 + 手機(jī)網(wǎng)站，以及營(yíng)銷(xiāo)，就是需要本來(lái)專(zhuān)注于移動(dòng)端研發(fā)定位的BaaS，向PaaS化和SaaS前進(jìn)。架構(gòu)上是基礎(chǔ)組件需要進(jìn)行升級(jí)，數(shù)據(jù)訪(fǎng)問(wèn)層、RPC、日志、監(jiān)控系統(tǒng)等。于是我們提出一個(gè)目標(biāo)，就是平臺(tái)化，數(shù)據(jù)訪(fǎng)問(wèn)的組件以PaaS形式提供給開(kāi)發(fā)者和內(nèi)部團(tuán)隊(duì)，標(biāo)準(zhǔn)化API網(wǎng)關(guān)、日志、監(jiān)控系統(tǒng)。

? ? ? ?設(shè)計(jì)上依然延續(xù)穩(wěn)定、成熟、解決問(wèn)題的思路。網(wǎng)關(guān)服務(wù)作為所有請(qǐng)求的入口，穩(wěn)定、性能、水平擴(kuò)展是考慮的要素。數(shù)據(jù)訪(fǎng)問(wèn)層，就像一個(gè)項(xiàng)目的大動(dòng)脈，所有的訪(fǎng)問(wèn)壓力、瓶頸、安全問(wèn)題會(huì)在這里匯合，如何構(gòu)建一條數(shù)據(jù)訪(fǎng)問(wèn)的高速公路是我們的目標(biāo)。日志和監(jiān)控，雖然沒(méi)有業(yè)務(wù)系統(tǒng)那么核心，但是關(guān)鍵時(shí)刻出現(xiàn)問(wèn)題需要排查時(shí)他們很大程度會(huì)影響解決問(wèn)題的效率，好的監(jiān)控系統(tǒng)能第一時(shí)間把正確的信號(hào)通知到正確的人，而爛的監(jiān)控只會(huì)為運(yùn)維帶來(lái)困擾。

? ? ? ?我們?cè)O(shè)計(jì)網(wǎng)關(guān)的初衷是替代掉Nginx，在自研的網(wǎng)關(guān)上控制規(guī)則轉(zhuǎn)發(fā)、主機(jī)注冊(cè)、容器狀態(tài)檢查、負(fù)載均衡、服務(wù)拒絕、限速等功能。Nginx是非常優(yōu)秀的一個(gè)軟件，也滿(mǎn)足一部分網(wǎng)關(guān)的功能，但是無(wú)法滿(mǎn)足我們不斷進(jìn)化的需求。

? ? ? ?整個(gè)網(wǎng)關(guān)系統(tǒng)由規(guī)則控制組件和容器管理組件兩部分組成。后的服務(wù)在啟動(dòng)后，向Hydra-容器管理組件，注冊(cè)自己的服務(wù)、IP地址和端口信息，Hydra隨后接管容器的生命周期管理，進(jìn)行健康檢查，F(xiàn)ailover處理，并把相關(guān)的信息保存在Zookeeper和MySQL中。規(guī)則控制組件在請(qǐng)求到達(dá)后，進(jìn)行規(guī)制匹配、路由轉(zhuǎn)發(fā)、限制、限速等處理。

? ? ? ?目前網(wǎng)關(guān)用在了大多數(shù)服務(wù)中，下步計(jì)劃是所有服務(wù)統(tǒng)一由網(wǎng)關(guān)進(jìn)行管理，下圖是網(wǎng)關(guān)系統(tǒng)的最終形態(tài)。

圖7 3.0網(wǎng)關(guān)架構(gòu)

? ? ? ?結(jié)構(gòu)化的業(yè)務(wù)數(shù)據(jù)主要存儲(chǔ)在MySQL和MongoDB中，設(shè)計(jì)上我們?cè)黾恿藬?shù)據(jù)代理層，代理層完全兼容MySQL和MongoDB的數(shù)據(jù)訪(fǎng)問(wèn)協(xié)議，讓開(kāi)發(fā)人員對(duì)代理完全無(wú)感，表面上是在訪(fǎng)問(wèn)特定的數(shù)據(jù)庫(kù)，實(shí)際上連接上數(shù)據(jù)代理后，由代理對(duì)數(shù)據(jù)操作做解析和路由。

? ? ? ?當(dāng)然，如果是僅僅實(shí)現(xiàn)代理的功能，有很多開(kāi)源項(xiàng)目可以使用比如MyCat、MySQL Proxy等，我們對(duì)代理有這些需求，數(shù)據(jù)訪(fǎng)問(wèn)路由和配置變更，數(shù)據(jù)訪(fǎng)問(wèn)鑒權(quán)和處理，日志采集發(fā)送，流控和服務(wù)拒絕。

圖8 3.0公共組件架構(gòu)

? ? ? ?設(shè)計(jì)之初也有考慮自己研發(fā)，通過(guò)調(diào)研后發(fā)現(xiàn)ElasticSearch + Logstash + Kibana完全滿(mǎn)足我們的需求，并且ES的生態(tài)和社區(qū)非?；钴S。通過(guò)早期幾個(gè)服務(wù)的試水，最終決定整個(gè)平臺(tái)基于ELK構(gòu)建日志系統(tǒng)。

? ? ? ?我們是這樣做的，在每臺(tái)主機(jī)上部署Logstash Angent采集格式化的日志數(shù)據(jù)，向Logstash Server發(fā)送日志。為了降低運(yùn)維成本，我們把Logstash Forward做成Docker鏡像，通過(guò)Salt來(lái)管理所有的Agent。Logstash Server在拿到日志信息后，不做任何規(guī)則上的處理，將數(shù)據(jù)保存在ES中。其實(shí)Logstash Server自身有日志解析和格式化的功能，但這樣做會(huì)嚴(yán)重影響它的吞吐量，于是我們的方案是把日志標(biāo)準(zhǔn)的流程控制在源頭。接下來(lái)，在Kibana中建立各種服務(wù)的面板和視圖，便可以進(jìn)行瀏覽和檢索了，還可以周期對(duì)日志進(jìn)行rotate、分析。

圖9 3.0日志系統(tǒng)

? ? ? ?基于日志系統(tǒng)的基礎(chǔ)架構(gòu)，不同服務(wù)將Metrics輸出到文件系統(tǒng)，通過(guò)LogStash和ES收集。在Kibana中定義視圖，Kibana使用ES作為自己的存儲(chǔ)引擎。比如新增一個(gè)視圖后，Kibana會(huì)在ES的.kibana這個(gè)索引中創(chuàng)建一份視圖的定義。

? ? ? ?有了Metrics數(shù)據(jù)和視圖的展示，下一步是報(bào)警。利用Nagios的報(bào)警機(jī)制，基于JNRPE實(shí)現(xiàn)報(bào)警的邏輯。報(bào)警邏輯通過(guò)讀取ES中.kibana某一個(gè)視圖的定義，和對(duì)應(yīng)的閾值設(shè)置，通過(guò)比較當(dāng)前值和閾值，返回某一個(gè)服務(wù)對(duì)應(yīng)特定指標(biāo)的監(jiān)控狀態(tài)。Nagios拿到狀態(tài)后，決定是否報(bào)警。

圖10 3.0監(jiān)控系統(tǒng)

? ? ? ?相比較2.0時(shí)期，統(tǒng)一了主要的基礎(chǔ)組件，降低了不同服務(wù)之間重復(fù)勞動(dòng)部分。通過(guò)日志系統(tǒng)也提升了定位問(wèn)題的效率，接下來(lái)還會(huì)考慮實(shí)現(xiàn)一套自己的請(qǐng)求trace系統(tǒng)，希望能夠跟蹤整個(gè)請(qǐng)求的生命周期，為尋找問(wèn)題和定位性能瓶頸做參考。

? ? ? ?從應(yīng)用到平臺(tái)，公司業(yè)務(wù)和產(chǎn)品定位在不斷的演進(jìn)，架構(gòu)也隨之發(fā)生了天翻地覆的變化。有一點(diǎn)是我們研發(fā)人員時(shí)刻要提醒自己的，不能脫離業(yè)務(wù)去談技術(shù)，滿(mǎn)足業(yè)務(wù)是原動(dòng)力，一切拋開(kāi)業(yè)務(wù)去空談架構(gòu)的做法都是耍流氓。

? ? ? ?成熟簡(jiǎn)單的技術(shù)就是最合適的，踩坑在所難免，但是如何把有限的資源用于做對(duì)的事情，不僅對(duì)商業(yè)和產(chǎn)品適合，對(duì)研發(fā)也同樣適合?；ヂ?lián)網(wǎng)公司多數(shù)都有由小團(tuán)隊(duì)、小想法、小產(chǎn)品，一步步發(fā)展起來(lái)的，在這個(gè)過(guò)程中能夠通過(guò)設(shè)計(jì)和決策，在正確的時(shí)間做正確的事情，讓產(chǎn)品能夠快速迭代，快速上線(xiàn)，才是架構(gòu)人員最需要考慮的事情。

相關(guān)閱讀：
移動(dòng)云平臺(tái)的基礎(chǔ)架構(gòu)之旅-云應(yīng)用篇
移動(dòng)開(kāi)發(fā)篇_暢談移動(dòng)云平臺(tái)之云代碼的基礎(chǔ)架構(gòu)設(shè)計(jì)
微服務(wù)系統(tǒng)中的服務(wù)發(fā)現(xiàn)機(jī)制

作者系力譜宿云 LeapCloud 團(tuán)隊(duì)_云服務(wù)負(fù)責(zé)人：秦鵬【原創(chuàng)】
首發(fā)地址：https://blog.maxleap.cn/archives/940

2014.02 加入上海力譜宿云團(tuán)隊(duì)，啟動(dòng)云平臺(tái)的研發(fā)
負(fù)責(zé)公司 MaxLeap，MaxWon 后端研發(fā)和維護(hù)工作
現(xiàn)任架構(gòu)和服務(wù)部負(fù)責(zé)人
關(guān)注分布式存儲(chǔ)、緩存、中間件、容器技術(shù)、微服務(wù)、公有云等領(lǐng)域

作者譯作：
微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到發(fā)布（一）
微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到發(fā)布（二）

歡迎關(guān)注微信訂閱號(hào)：從移動(dòng)到云端（主推技術(shù)活動(dòng)信息+技術(shù)文）
歡迎加入我們的力譜宿云 LeapCloud 活動(dòng)QQ群：555973817，我們將不定期做技術(shù)分享活動(dòng)。

若有轉(zhuǎn)載需要，請(qǐng)轉(zhuǎn)發(fā)時(shí)注意自帶作者信息一欄并本自媒體公號(hào)：力譜宿云 LeapCloud，尊重原創(chuàng)作者的勞動(dòng)成果~ 謝謝配合~

近期線(xiàn)下技術(shù)活動(dòng)預(yù)告：

活動(dòng)主題：【技術(shù)分享】Vert.x中國(guó)用戶(hù)組（上海地區(qū)）第一次技術(shù)沙龍
分享內(nèi)容：

分享主題1：JVM上的高性能Reative工具Vert.x3介紹

分享主題1：Vert.x在maxleap的最佳實(shí)踐

分享主題1：Vert－web注解封裝

活動(dòng)時(shí)間：2016/07/24(周日) 14:00 至 2016/07/24 17:00 ?
活動(dòng)場(chǎng)地：上海浦東新區(qū)金科路2889弄（近祖沖之路）長(zhǎng)泰廣場(chǎng)C座12層
報(bào)名鏈接：http://www.hdb.com/party/ydtru-comm.html