在社會高速發(fā)展的今天，高強度的工作、長期地奔波忙碌導致健康透支、疾病上身，“健康生活”變成奢望，“智能手環(huán)”應運而生。智能手環(huán)更像是健康的監(jiān)督官，能時刻提醒你關注自己的身體健康狀態(tài)，督促你多做運動、合理飲食、注意睡眠。為超萬千家庭和個人提供健康電子產(chǎn)品的樂心便是個中翹楚，而其中最為突出的產(chǎn)品便是“樂心手環(huán)”。
然而，如何為用戶提供更好的手環(huán)使用體驗，“智能硬件”并不是做好設備本身就可以滿足了，這中間還包括“軟硬兼施”的過程，移動APP、微信客戶端的體驗也額外重要，智能硬件背后的技術實踐之道值得我們?nèi)ド钔凇?/p>
樂心手環(huán)產(chǎn)品內(nèi)部架構
智能硬件業(yè)務帶來的挑戰(zhàn)：業(yè)務規(guī)律
與傳統(tǒng)業(yè)務不同，智能硬件的業(yè)務規(guī)律會有兩個峰值。
參照上圖，左邊為常見的業(yè)務規(guī)律圖，從早晨7點之后吞吐率持續(xù)穩(wěn)定，直到凌晨。智能硬件的業(yè)務規(guī)律與我們的生活息息相關，右邊為智能硬件的業(yè)務規(guī)律，早晨7點左右是一個峰值，晚上9點左右是另外一個峰值。
想象一下，我們清晨起來，打開手機，查看昨晚的睡眠質(zhì)量如何，然后用智能血壓計量一下血壓，之后再用智能稱下體重，這時候，帶來的業(yè)務流量大部分是基礎數(shù)據(jù)流量，成為第一個峰值。
晚上9點左右，微信運動會主動推送每日行走的步數(shù)，同時，我們也會打開手環(huán)的公眾帳號，查看朋友圈步數(shù)排名。因此會形成第二個峰值，晚上9點的峰值會是7點峰值的3倍左右。
人群準時的在21點蜂擁而至，似乎每天都在上演著搶購大戰(zhàn)，作為運維團隊，面臨著一系列的挑戰(zhàn)：
如何快速保障相差3倍的峰值？
如何高效較少資源浪費？
如何快速迭代，敏捷地解決舊問題？
帶著這樣的問題，樂心手環(huán)有了以下的技術解決方案。
技術瓶頸推動新技術的使用
樂心健康管理業(yè)務架構
A.后端架構：自建Docker+微服務+Dubbo框架
B.前端應用：Wechat+APP+H5
樂心健康管理平臺技術架構
在開發(fā)樂心健康平臺1.0時，服務端采用傳統(tǒng)的單服務多集群的架構，發(fā)現(xiàn)在用戶量基數(shù)大請求并發(fā)大并且對響應速度要求高的情況下存在難以攻克的技術難點，如：
（1）所有業(yè)務數(shù)據(jù)存儲在同一數(shù)據(jù)庫，難以橫向擴展
（2）不能針對請求量大的單一功能進行擴容，必須整個應用平臺集群擴容過多占用硬件資源
（3）業(yè)務模塊不能很好進行解耦，代碼過于臃腫，增加新業(yè)務功能時容易影響到舊的業(yè)務
問題的產(chǎn)生便促發(fā)了在樂心健康平臺2.0服務端技術選型時使用微服務化的架構，按功能模塊劃分成微服務后能很方便的針對單一功能進行擴容，并能更穩(wěn)定的支持了更大的用戶量與更多的并發(fā)請求。
智能手環(huán)開展敏捷開發(fā)
伴隨著公司業(yè)務的持續(xù)穩(wěn)健上升，產(chǎn)品種類、合作伙伴以及用戶數(shù)也越來越多。產(chǎn)品規(guī)劃、運營訴求、合作方式的拓展以及客戶的反饋，都帶來大量的開發(fā)需求，同時許多需求都是具備較強時效性的，如運營推廣以及對外合作。
為了支持持續(xù)涌現(xiàn)的開發(fā)需求：
1、技術和產(chǎn)品建立了需求池，并對需求按照優(yōu)先級和緊急程序進行分類
2、由產(chǎn)品和研發(fā)共同確定一個迭代周期需要實現(xiàn)的需求項并形成版本計劃，為了滿足需求的時效性以及快速獲取市場反饋，樂心手環(huán)的迭代周期一般控制在2個星期。 每個迭代周期內(nèi)，相關的產(chǎn)品、研發(fā)以及測試以項目小組的形式進行協(xié)同工作（同時會存在多個這樣的小組），通過每日晨會的方式及時反饋進度、風險、遇到的問題點。
表面上看，研發(fā)流程采用的是典型的SCRUM敏捷模式，但是有一些不同。SCRUM敏捷模式主張響應需求變化，但是因為缺乏系統(tǒng)性的設計，對團隊成員自身的素質(zhì)要求較高，否則難以保證研發(fā)質(zhì)量，反而會因為研發(fā)質(zhì)量的不合格影響后面的迭代，招致線上事故和客戶投訴。
因此，樂心技術團隊結(jié)合了自身的產(chǎn)品特點以及研發(fā)團隊總體水平，從穩(wěn)健出發(fā)，將傳統(tǒng)瀑布模式中具有系統(tǒng)性和預見性的軟件架構設計嵌套到敏捷開發(fā)的輕量級的迭代中，并根據(jù)每次迭代的內(nèi)容，調(diào)整軟件架構設計的深入程序，實現(xiàn)敏捷開發(fā)與瀑布模型軟件架構設計融合的雙贏。
樂心的高效DevOps: Docker＋微服務+APM
Docker
互聯(lián)網(wǎng)不斷涌現(xiàn)出新技術, Docker就是這其中非常重要的一個。2015年，樂心已經(jīng)對Docker做了知識儲備,但當時并沒有急于用于生產(chǎn)環(huán)境。條件的不成熟,場景的不適合使得樂心暫緩了Docker的使用。樂心認為，不會因為是新技術而實用新技術,而是要考慮具體場景與面臨的問題。
生產(chǎn)環(huán)境的部署方式,主要取決于程序架構。樂心的程序從單一應用過渡到微服務應用。首先運維的工作面臨比較大的挑戰(zhàn),以前幾個代碼倉庫發(fā)展成幾十個倉庫，需要負責幾十個程序的幾個百節(jié)點的部署與版本更新。同時需要保證測試環(huán)境與線上環(huán)境的程序一致性。此時引入Docker恰巧能很好的解決這些問題。樂心 Docker自建的過程,主要是圍繞著測試環(huán)境自建與生產(chǎn)環(huán)境自建，當然這也是一個逐步摸索的過程。
A.測試環(huán)境自建
1.使用jenkins編譯代碼構建docker鏡像
2.使用開源的配置中心(disconf),實現(xiàn)配置的集中管理,也同時保證了鏡像在不同環(huán)境下的一致性
3.使用docker-compose 運行docker鏡像
4.使用shipyard開源pass平臺,提供給研發(fā)人員重啟服務與查看終端日志
B.生產(chǎn)環(huán)境的自建
1.建立 docker-registry 鏡像倉庫
2.建立中央日志系統(tǒng),程序在容器中盡可能地避免輸出終端日志,而是發(fā)送到日志系統(tǒng)
3.使用kubernetes部署與管理微服務鏡像
4.使用zabbix對容器可用性狀態(tài)進行監(jiān)控
微服務
樂心將整體業(yè)務進行建模，按照功能模劃分成不同的微服務。微服務區(qū)分為服務接入層和業(yè)務處理層，服務接入層負責安全校驗、請求參數(shù)的合法性校驗、通過Dubbo形式調(diào)用業(yè)務處理層并封裝數(shù)據(jù)響應前端請求，業(yè)務處理層負責處理業(yè)務邏輯和數(shù)據(jù)持久化。每個微服務部署多個節(jié)點，使用獨立數(shù)據(jù)庫和緩存。
在樂心健康平臺2.0微服務化過程中遇到在抽取獨立服務建模時出現(xiàn)服務邊界不清晰，服務間業(yè)務存在相互依賴的情況。因此使用了MQ消息進行服務間的通訊，避免了服務直接依賴調(diào)用。微服務化之后服務節(jié)點增多，每個服務的配置文件變得不易于管理，為了更好的解決分布式環(huán)境下多臺服務實例的配置統(tǒng)一管理問題，引入了一套完整的分布式配置管理解決方案。
APM
A.研發(fā)角度
從研發(fā)角度來看，據(jù)非權威統(tǒng)計，頁面響應時間增加1秒，就會降低7%的訪問量。顯然，響應時間緩慢對目標用戶的積累、業(yè)務推廣以及企業(yè)發(fā)展都是極大的破壞。因此就需要盡可能的縮短響應時間提高用戶的使用體驗�？扇绾慰s短響應時間呢？最耗時的是哪個環(huán)節(jié)呢？為什么消耗那么長時間呢？能不能接近真實的還原線上的實際處理情況呢？能不能幾乎實時的掌握線上服務的性能，在客戶反饋、投訴之前解決風險呢？傳統(tǒng)的解決方案是依靠開發(fā)人員在代碼里面添加大量的日志，記錄調(diào)用鏈路，記錄每一次調(diào)用各個環(huán)節(jié)的消耗時間，當遇到客戶反饋時，通過糾集各種日志，人工整理分析……響應慢，信息收集不全，信息不連續(xù)，造成不僅效率低下，成本頗高，而且客戶還不滿意。 這就是APM需要解決的問題。
從業(yè)務上看，樂心的終端用戶可以既包括真實用戶，又包括需要上傳數(shù)據(jù)的設備。真實用戶對設備數(shù)據(jù)是否及時上傳感知很敏銳，因此，就需要保證服務能夠高性能的持續(xù)穩(wěn)定運行。借助APM監(jiān)測采集的數(shù)據(jù)，一方面保證數(shù)據(jù)的完整性及時性，另一方面信息的連貫性，真實性，可以極大的幫助我們優(yōu)化服務，及時感知服務異常并提前介入，化解性能問題于無形。
B.運維角度
隨著用戶數(shù)量不斷增長, 樂心醫(yī)療也會面臨程序性能的問題, 在缺乏APM工具的情況下,運維和開發(fā)對性能異常的排查,往往需要投入比較多的時間與及比較高層次的技術人員,而且往往是線上出現(xiàn)故障之后,造成了不可挽回的損失。APM工具恰恰能夠很好處理這個問題。首先，能夠?qū)Ξ惓７⻊者M行快速定位；其次，對程序的異常進行提前感知,可以在服務還是在可運行狀態(tài)下,爭取時間優(yōu)化。
聽云APM為樂心手環(huán)提供了重要支持：
1、樂心將聽云APM納入了整個研發(fā)的流程中,能夠充分展現(xiàn)壓力測試所需要的指標。同時聽云APM長期的統(tǒng)計報表,已經(jīng)作為了優(yōu)化程序的重要性能依據(jù),納入到版本規(guī)劃中。
2、傳統(tǒng)的應用是由三層組合：UI層、處理層、數(shù)據(jù)庫層，是一個縱向的流量。這樣的優(yōu)勢便是簡單，但劣勢時縱向串聯(lián)很容易造成瓶頸，所以市面上推出了分布式部署，即將三層分別做多個主備，不讓每一個環(huán)節(jié)造成瓶頸。這個瓶頸即是解耦。因此，微服務應運而生。微服務化的誕生推動了架構發(fā)展的同時也帶來了復雜的調(diào)用鏈，以及需要面對的服務治理問題。
微服務架構對運維和部署流水線要求非常高，服務拆分的粒度越高，運維和治理成本就越高，挑戰(zhàn)如下：
（1）監(jiān)控度量問題：海量微服務的各種維度性能KPI采集、匯總和分析，實時和歷史數(shù)據(jù)同比和環(huán)比等，對采集模塊的實時性、前端運維Portal多維度展示能力要求非常高。
對此，聽云APM強大的數(shù)據(jù)管理能夠精準的解決監(jiān)控度量所需的要求。
A.聽云App監(jiān)測的數(shù)據(jù)覆蓋5億月活的App，有著大量的數(shù)據(jù)積累，服務了12個行業(yè)72個子行業(yè)，在對應用分類的基礎上，再對終端設備數(shù)據(jù)進行分類，可產(chǎn)生行業(yè)屬性的大數(shù)據(jù)，為移動App的監(jiān)測提供強大幫助。
聽云App－網(wǎng)絡請求
B.聽云Network擁有30萬節(jié)點，累計產(chǎn)生36億次的撥測，每一次的撥測訪問，都是對用戶web質(zhì)量的探測。
C.在對服務端監(jiān)測上，聽云Server所監(jiān)測的應用主機數(shù)突破了20000臺，對多云主機應用的性能監(jiān)測，對多語言環(huán)境、關系型數(shù)據(jù)庫／非關系型數(shù)據(jù)庫、框架、外部服務監(jiān)測的支持為微服務所需的各種維度性能的數(shù)據(jù)采集、展示、分析提供了有力支撐。
聽云Server-Web應用過程
（2）分布式運維：服務拆分得越細，一個完整業(yè)務流程的調(diào)用鏈就越長，需要采集、匯總和計算的數(shù)據(jù)量就越大，分布式消息跟蹤系統(tǒng)需要能夠支撐大規(guī)模微服務化后帶來的性能挑戰(zhàn)。
對此，聽云APM的全棧溯源功能可以幫助技術人員非�？焖佟⒈憬莸拿枋稣麄�調(diào)用鏈條,快速的找到問題的元兇：具體說就是它能夠幫助降低跨部門排障溝通成本，快速追溯性能問題根源，同時能夠幫助進行性能問題界定，協(xié)助運維明確責任，協(xié)助研發(fā)修改問題，最重要的是它可以完整幫助業(yè)務、研發(fā)、運維進行業(yè)務調(diào)用鏈跟蹤。
3、Docker作為短生命周期應用,隨著版本迭代而更替實例, 在這個過程中，聽云提供的APM服務能夠以非常友好的方式沉淀歷史數(shù)據(jù),讓樂心看到版本迭代前后性能的變化。