诸葛io的技术架构图_大数据平台的三次浪潮和诸葛io自身架构演变历程 (3)

我们会由统一的数据访问层来输出数据，给应用层进行调用。这一层我们会封装一些分析模型和业务逻辑，数据访问层会分为内部接口和外部接口进行分发。

6) 数据应用系统

我们的数据应用主要包括以下部分：

a. 诸葛io网站。网站是zhugeio.com 提供给企业客户交互式自助分析的平台，包括了丰富的功能。

b. 内部服务。主要是DevOps和业务监控平台需要调用一些接口进行状态监控和跟踪，保障服务质量以及稳定性。

c. 数据挖掘。诸葛io有算法组和分析组两支队伍对数据进行一些复杂的挖掘和分析，包括：

i)   用户行为路径挖掘

ii)   行业模型和看板

iii)  流失和预测分析

iv) 自动化的分析报告

d. 开放API。我们提供给客户的不仅仅是汇总统计的数据，还允许用户直接访问和导出自己的原始数据和加工后的数据，因此我们把一些查询封装成了API的逻辑，允许客户进行二次开发或者调用，所以我们有一个开放的API平台。

诸葛io的架构经历了两次迭代，目前正在进行第三次的重构。我们重构的目的包含两方面：第一次重构主要是技术方案的瓶颈突破，第二次重构主要是业务领域问题的延伸和拓展。

架构永远是贴合业务的。诸葛io是新一代分析平台里面最早上线的。我们从2014年10月开始研发，上线于 15年3月份。当时，我们需要让产品快速上线，验证想法，所以架构搭建的比较简单，包括我在内的6个工程师，完成了整套从数据采集到数据处理到网站到前端 可视化的大数据架构。由于我们的研发团队在大数据领域经验比较丰富，能解决各种技术难题。当时我们搭建的简单架构如图5：

图5：诸葛io第一次上线的架构实践

初次上线的架构在刚开始的一段时间内一切正常。随着业务发展，诸葛io的客户量逐步增加，如暴走漫画、小影、墨迹天气等大体量的客户陆续接入平台，这个时候也面临着诸多考验。

2.诸葛第一次上线架构数据处理流的架构图：

图6：诸葛io第一次上线的数据处理流

1)数据上传延时高。上传延时很高主要有两方面：

a. HTTPS建立连接和加密验证过于耗时。HTTPS比普通的Http的三次握手多一个SSL验证过程，我们第一次上线使用的是比较老的Nginx，并且只有单Nginx的支撑，握手压力过大。虽 然我们在系统参数调优上做了很多尝试，但是本质还是需要一次架构优化，因此选择了在Nginx前加了一个LVS，把Nginx升级到最新版，并且支持了 HTTP2的协议，扩展了Nginx的服务器数量。

b.  数据上传模块的设计缺陷。诸葛io之前的数据上传模块逻辑是：客户端上传数据到服务端，服务端接收后会解压并且加入一些上传的IP、上传时间等字段，然继而写入到Kafka消息队 列中，然后返回给客户处理结果。这个过程不需要客户端等待处理过程，需要我们团队进行优化，优化后的逻辑是客户端上传成功后即返回。我们之前的服务端是用 C++编写的，我们直接参考一些秒杀的高并发架构进行了优化，在选择了Nginx+Lua后，在没有数据丢失的情况下，单节点每秒并发处理完成数提高了5 倍多。

2)数据处理流使用的是多java进程方式

我们在第一次架构过程中，对于各个子业务处理的都是独立的java程序进行数据消费和处理，由于这种方式不利于我们后续的业务扩展和运维管理，有很大的隐患，我们将其改成了通过Samza平台的处理过程。选择Samza的主要原因是，处理的输入输出都是Kafka，并且Samza的实时性也有保证。

3)数据仓库不具有可伸缩性