【51CTO.com原创稿件】2017年12月01-02日，由51CTO主办的WOTD 2017全球软件开发技术峰会在深圳中洲万豪酒店召开。自2012年以来，WOT品牌大会成功举办了14届，积累了大量的技术专家资源，获得了广大IT从业者和技术爱好者的一致认可，成为了业界重要的技术分享交流平台以及人脉拓展平台。本次会议包含：编程语言与框架，大数据系统架构设计、微服务与容器技术、前端开发实战、物联网(IoT)技术、软件性能优化等10大技术主题。
在大数据系统架构设计专场，来自TalkingData的资深Java工程师何坤分享了主题为《高可用数据服务交易系统架构实践》精彩演讲，介绍了TalkingData在搭建高可用数据服务系统的过程中，准确计量系统的设计、实现和演进等内容。
演讲中，何坤介绍了TalkingData智能数据服务商城SDMK(Smart Data Market)。SDMK是什么?它提供多种形式的数据服务，包括 API 服务、人群数据服务、异步服务等，还开放了Lookalike，情景感知，预测引擎，推荐引擎等人工智能服务。通过这些数据服务，可以降低数据应用场景的难度，帮助更多企业发现数据的深层价值。
所谓实践出真知，谈及智能数据服务商城实践的经验心得，何坤从如何保证数据服务交易系统的高可用，如何做到准确计量等多个方面与51CTO记者进行了交流。
如何搭建高可用的数据服务交易系统?
作为基础设施，有很多应用依赖于SDMK提供的服务,SDMK的自身的总体可用性必须比它们还要高。考虑到南向服务的多样性和不可靠性，虽然不能做服务本身的可用性保证，但是要能做到服务不可用时，能以合适的方式通知用户。因此，在SDMK构建过程中，TalkingData技术团队充分考虑了系统的可用性。
何坤表示，想要搭建一个高可用的数据服务交易系统，不仅要做好梳理好业务流程，划分出具体的系统功能模块等这些常规工作。同时，在可用性上，系统需要达到两点要求：一是，计量最终误差要求，不高于0.01%;二是，交易系统可用性要求，不低于99.9%。
如何做到准确计量，保证计量误差不高于0.01%?
那么，我们究竟该如何做到准确计量?对此，何坤认为，首先我们要明确准确计量的概念，它有两层含义：一是，实时数量的准确性;二是，最终数量的准确性。但实时准确与高并发是一对矛盾，因此只能做到最终准确+高并发，牺牲一定的实时数量准确性，也就是说，实时计量会有一定误差。因此，我们需要在保证最终准确性的前提下，尽量提高实时准确性。
此外，为了保证服务高并发和高QPS下服务的响应时间，可以使用“异步计量”的方式。在发生故障时，选择尽量确保服务可用，容忍可能的超量;在故障后恢复数据，满足最终准确的要求。
何坤表示，之所以选择“异步计量”的方式而不是“同步计量”的方式，是因为：
1.对数据库压力大;
2.每次调用时延变长，不容易保证主流程时延稳定;
3.MySQL不易扩展，要做分库分表;
4.异步计量容易洗数;
5.扩展性好，牵涉到异步服务的所有组件，ES，Kafka，Redis都是原生就支持方便扩展的。
此外，为了保证最终一致性，同时让实时准确性尽量达到目标，TalkingData采用了Lambda架构来降低准确性和高并发下实时的矛盾。
如何保证系统可用性不低于99.9%?
记者了解到，整体服务的高可用性，不止故障转移这一个点，它包括四个方面：事前的预防、事中的自动化故障转移、事中的故障感知、事后的故障恢复。
何坤表示：“可用性背后是故障，我们预防故障的发生，在故障发生的时候及时做到故障转移和故障的感知，并且在感知到故障之后能比较快速地恢复故障，恢复之后能做到复盘或者改进，就回到预防这一环，形成良性的循环。”
要想保证交易系统可用性不低于99.9%，何坤建议可以这样做：
***，采用分布式部署，无状态设计。采用服务无状态设计，把必要的状态保存在中央存储中(MySQL/Redis等);所有调用必须带trackid，以便定位问题，缩短故障恢复时间。
第二，可以专注于核心业务，降低关键路径复杂性与负载，并适时拆分和合并功能模块，降低模块复杂度。
第三，对资源的使用进行限制，避免无效调用或者故障耗尽资源。可采用熔断机制，分服务SLA，独立适配器，限制pending状态等方式，从用户和服务两个方向来进行。
第四，消息系统的选择需要能够保证数据可持久化，支持订阅和队列两种方式，具有高性能和高扩展性。
第五，做好监控与报警。所有服务上线之前必须有基本监控与报警，比如：基础组件监控与报警、业务指标监控与报警、调用追踪系统等。
第六，减少更新带来的故障，因为大多数故障都是更新引起的。对此，可以采用灰度系统，基于用户id分流，而不是随机分流。无论gateway请求还是页面请求，所有的请求都带用户id，因此可以基于这个特性在Nginx中写Lua来识别用户，读取后端配置的灰度用户列表，决定是进入灰度系统还是正式生产系统。接入灰度的可以是友好用户，也可以是守护用户。但是要注意做好守护用户数据的隔离，不要污染生产数据的统计分析。
此外，何坤强调，为了保证系统的高可用，一方面，要做好功能实现的演练测试;另一方面，研发人员需要深入地切入到运维层面，因为开发出的产品并不是实现了所有功能就是完成了任务，还需要发现并解决产品运行过程中存在的问题，否则会出现脱节的情况。
***，何坤表示，在设计系统时，除了计量本身的逻辑之外，计量是和可用性是密切联系在一起的。如果可用性不够高，或者不能及时纠正运行过程中的错误，那么就会影响计量。比如：如果不能快速的恢复数据，那么准确性也无法保证。
【讲师简介】
TalkingData资深Java工程师何坤
何坤主要负责Smart Data Market研发，主导开发了智能数据服务商城，为超过200家客户以高SLA提供数百个在线数据服务。在基于微服务的高并发高可用Saas系统设计实现运营方面具有丰富经验。之前曾任职于甲骨文，安捷伦科技等公司。敏捷开发和DevOps的践行者。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
