听云APM与乐心手环：智能硬件背后的技术实践

　　在社会高速发展的今天，高强度的工作、长期地奔波忙碌导致健康透支、疾病上身，“健康生活”变成奢望，“智能手环”应运而生。智能手环更像是健康的监督官，能时刻提醒你关注自己的身体健康状态，督促你多做运动、合理饮食、注意睡眠。为超万千家庭和个人提供健康电子产品的乐心便是个中翘楚，而其中最为突出的产品便是“乐心手环”。

　　然而，如何为用户提供更好的手环使用体验，“智能硬件”并不是做好设备本身就可以满足了，这中间还包括“软硬兼施”的过程，移动APP、微信客户端的体验也额外重要，智能硬件背后的技术实践之道值得我们去深挖。

乐心手环产品内部架构

　　智能硬件业务带来的挑战：业务规律

　　与传统业务不同，智能硬件的业务规律会有两个峰值。

　　参照上图，左边为常见的业务规律图，从早晨7点之后吞吐率持续稳定，直到凌晨。智能硬件的业务规律与我们的生活息息相关，右边为智能硬件的业务规律，早晨7点左右是一个峰值，晚上9点左右是另外一个峰值。

　　想象一下，我们清晨起来，打开手机，查看昨晚的睡眠质量如何，然后用智能血压计量一下血压，之后再用智能称下体重，这时候，带来的业务流量大部分是基础数据流量，成为第一个峰值。

　　晚上9点左右，微信运动会主动推送每日行走的步数，同时，我们也会打开手环的公众帐号，查看朋友圈步数排名。因此会形成第二个峰值，晚上9点的峰值会是7点峰值的3倍左右。

　　人群准时的在21点蜂拥而至，似乎每天都在上演着抢购大战，作为运维团队，面临着一系列的挑战：

　　如何快速保障相差3倍的峰值？

　　如何高效较少资源浪费？

　　如何快速迭代，敏捷地解决旧问题？

　　带着这样的问题，乐心手环有了以下的技术解决方案。

　　技术瓶颈推动新技术的使用

乐心健康管理业务架构

　　A.后端架构：自建Docker+微服务+Dubbo框架

　　B.前端应用：Wechat+APP+H5

乐心健康管理平台技术架构

　　在开发乐心健康平台1.0时，服务端采用传统的单服务多集群的架构，发现在用户量基数大请求并发大并且对响应速度要求高的情况下存在难以攻克的技术难点，如：

　　（1）所有业务数据存储在同一数据库，难以横向扩展

　　（2）不能针对请求量大的单一功能进行扩容，必须整个应用平台集群扩容过多占用硬件资源

　　（3）业务模块不能很好进行解耦，代码过于臃肿，增加新业务功能时容易影响到旧的业务

　　问题的产生便促发了在乐心健康平台2.0服务端技术选型时使用微服务化的架构，按功能模块划分成微服务后能很方便的针对单一功能进行扩容，并能更稳定的支持了更大的用户量与更多的并发请求。

　　智能手环开展敏捷开发

　　伴随着公司业务的持续稳健上升，产品种类、合作伙伴以及用户数也越来越多。产品规划、运营诉求、合作方式的拓展以及客户的反馈，都带来大量的开发需求，同时许多需求都是具备较强时效性的，如运营推广以及对外合作。

　　为了支持持续涌现的开发需求：

　　1、技术和产品建立了需求池，并对需求按照优先级和紧急程序进行分类

　　2、由产品和研发共同确定一个迭代周期需要实现的需求项并形成版本计划，为了满足需求的时效性以及快速获取市场反馈，乐心手环的迭代周期一般控制在2个星期。 每个迭代周期内，相关的产品、研发以及测试以项目小组的形式进行协同工作（同时会存在多个这样的小组），通过每日晨会的方式及时反馈进度、风险、遇到的问题点。

　　表面上看，研发流程采用的是典型的SCRUM敏捷模式，但是有一些不同。SCRUM敏捷模式主张响应需求变化，但是因为缺乏系统性的设计，对团队成员自身的素质要求较高，否则难以保证研发质量，反而会因为研发质量的不合格影响后面的迭代，招致线上事故和客户投诉。

　　因此，乐心技术团队结合了自身的产品特点以及研发团队总体水平，从稳健出发，将传统瀑布模式中具有系统性和预见性的软件架构设计嵌套到敏捷开发的轻量级的迭代中，并根据每次迭代的内容，调整软件架构设计的深入程序，实现敏捷开发与瀑布模型软件架构设计融合的双赢。

　　乐心的高效DevOps: Docker＋微服务+APM

　　Docker

　　互联网不断涌现出新技术, Docker就是这其中非常重要的一个。2015年，乐心已经对Docker做了知识储备,但当时并没有急于用于生产环境。条件的不成熟,场景的不适合使得乐心暂缓了Docker的使用。乐心认为，不会因为是新技术而实用新技术,而是要考虑具体场景与面临的问题。

　　生产环境的部署方式,主要取决于程序架构。乐心的程序从单一应用过渡到微服务应用。首先运维的工作面临比较大的挑战,以前几个代码仓库发展成几十个仓库，需要负责几十个程序的几个百节点的部署与版本更新。同时需要保证测试环境与线上环境的程序一致性。此时引入Docker恰巧能很好的解决这些问题。乐心 Docker自建的过程,主要是围绕着测试环境自建与生产环境自建，当然这也是一个逐步摸索的过程。

　　A.测试环境自建

　　1.使用jenkins编译代码构建docker镜像

　　2.使用开源的配置中心(disconf),实现配置的集中管理,也同时保证了镜像在不同环境下的一致性

　　3.使用docker-compose 运行docker镜像

　　4.使用shipyard开源pass平台,提供给研发人员重启服务与查看终端日志

　　B.生产环境的自建

　　1.建立 docker-registry 镜像仓库

　　2.建立中央日志系统,程序在容器中尽可能地避免输出终端日志,而是发送到日志系统

　　3.使用kubernetes部署与管理微服务镜像

　　4.使用zabbix对容器可用性状态进行监控