在社会高速发展的今天，高强度的工作、长期地奔波忙碌导致健康透支、疾病上身，“健康生活”变成奢望，“智能手环”应运而生。智能手环更像是健康的监督官，能时刻提醒你关注自己的身体健康状态，督促你多做运动、合理饮食、注意睡眠。为超万千家庭和个人提供健康电子产品的乐心便是个中翘楚，而其中最为突出的产品便是“乐心手环”。
然而，如何为用户提供更好的手环使用体验，“智能硬件”并不是做好设备本身就可以满足了，这中间还包括“软硬兼施”的过程，移动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对容器可用性状态进行监控
微服务
乐心将整体业务进行建模，按照功能模划分成不同的微服务。微服务区分为服务接入层和业务处理层，服务接入层负责安全校验、请求参数的合法性校验、通过Dubbo形式调用业务处理层并封装数据响应前端请求，业务处理层负责处理业务逻辑和数据持久化。每个微服务部署多个节点，使用独立数据库和缓存。
在乐心健康平台2.0微服务化过程中遇到在抽取独立服务建模时出现服务边界不清晰，服务间业务存在相互依赖的情况。因此使用了MQ消息进行服务间的通讯，避免了服务直接依赖调用。微服务化之后服务节点增多，每个服务的配置文件变得不易于管理，为了更好的解决分布式环境下多台服务实例的配置统一管理问题，引入了一套完整的分布式配置管理解决方案。
APM
A.研发角度
从研发角度来看，据非权威统计，页面响应时间增加1秒，就会降低7%的访问量。显然，响应时间缓慢对目标用户的积累、业务推广以及企业发展都是极大的破坏。因此就需要尽可能的缩短响应时间提高用户的使用体验。可如何缩短响应时间呢？最耗时的是哪个环节呢？为什么消耗那么长时间呢？能不能接近真实的还原线上的实际处理情况呢？能不能几乎实时的掌握线上服务的性能，在客户反馈、投诉之前解决风险呢？传统的解决方案是依靠开发人员在代码里面添加大量的日志，记录调用链路，记录每一次调用各个环节的消耗时间，当遇到客户反馈时，通过纠集各种日志，人工整理分析……响应慢，信息收集不全，信息不连续，造成不仅效率低下，成本颇高，而且客户还不满意。 这就是APM需要解决的问题。
从业务上看，乐心的终端用户可以既包括真实用户，又包括需要上传数据的设备。真实用户对设备数据是否及时上传感知很敏锐，因此，就需要保证服务能够高性能的持续稳定运行。借助APM监测采集的数据，一方面保证数据的完整性及时性，另一方面信息的连贯性，真实性，可以极大的帮助我们优化服务，及时感知服务异常并提前介入，化解性能问题于无形。
B.运维角度
随着用户数量不断增长, 乐心医疗也会面临程序性能的问题, 在缺乏APM工具的情况下,运维和开发对性能异常的排查,往往需要投入比较多的时间与及比较高层次的技术人员,而且往往是线上出现故障之后,造成了不可挽回的损失。APM工具恰恰能够很好处理这个问题。首先，能够对异常服务进行快速定位；其次，对程序的异常进行提前感知,可以在服务还是在可运行状态下,争取时间优化。
听云APM为乐心手环提供了重要支持：
1、乐心将听云APM纳入了整个研发的流程中,能够充分展现压力测试所需要的指标。同时听云APM长期的统计报表,已经作为了优化程序的重要性能依据,纳入到版本规划中。
2、传统的应用是由三层组合：UI层、处理层、数据库层，是一个纵向的流量。这样的优势便是简单，但劣势时纵向串联很容易造成瓶颈，所以市面上推出了分布式部署，即将三层分别做多个主备，不让每一个环节造成瓶颈。这个瓶颈即是解耦。因此，微服务应运而生。微服务化的诞生推动了架构发展的同时也带来了复杂的调用链，以及需要面对的服务治理问题。
微服务架构对运维和部署流水线要求非常高，服务拆分的粒度越高，运维和治理成本就越高，挑战如下：
（1）监控度量问题：海量微服务的各种维度性能KPI采集、汇总和分析，实时和历史数据同比和环比等，对采集模块的实时性、前端运维Portal多维度展示能力要求非常高。
对此，听云APM强大的数据管理能够精准的解决监控度量所需的要求。
A.听云App监测的数据覆盖5亿月活的App，有着大量的数据积累，服务了12个行业72个子行业，在对应用分类的基础上，再对终端设备数据进行分类，可产生行业属性的大数据，为移动App的监测提供强大帮助。
听云App－网络请求
B.听云Network拥有30万节点，累计产生36亿次的拨测，每一次的拨测访问，都是对用户web质量的探测。
C.在对服务端监测上，听云Server所监测的应用主机数突破了20000台，对多云主机应用的性能监测，对多语言环境、关系型数据库／非关系型数据库、框架、外部服务监测的支持为微服务所需的各种维度性能的数据采集、展示、分析提供了有力支撑。
听云Server-Web应用过程
（2）分布式运维：服务拆分得越细，一个完整业务流程的调用链就越长，需要采集、汇总和计算的数据量就越大，分布式消息跟踪系统需要能够支撑大规模微服务化后带来的性能挑战。
对此，听云APM的全栈溯源功能可以帮助技术人员非常快速、便捷的描述整个调用链条,快速的找到问题的元凶：具体说就是它能够帮助降低跨部门排障沟通成本，快速追溯性能问题根源，同时能够帮助进行性能问题界定，协助运维明确责任，协助研发修改问题，最重要的是它可以完整帮助业务、研发、运维进行业务调用链跟踪。
3、Docker作为短生命周期应用,随着版本迭代而更替实例, 在这个过程中，听云提供的APM服务能够以非常友好的方式沉淀历史数据,让乐心看到版本迭代前后性能的变化。