2.8 日志分析

日志是系统运行维护最重要的一个环节。系统如果缺少了日志等于全瞎全盲，当系统存在问题，或则宕机的时候。只有快速查看日志，针对日志报出来不同的错误，然后修复系统。一个百万级的系统每天都会产生大量的日志。日志会随着时间不短增长不断增长。所以传统shell查看日志是很难在庞大日志量中去寻找关键错误信息。虽然日志不断在增长，但是出问题系统是不会可以查询的。需要按照不同组件，不同模块去保存相关的日志即可。日志可以最终系统的运营情况。对日志的监控和切分可以快速的定位系统出现的状况。日志可以分为四个级别，分别为debug，info，warn，error。正确的日志分级可以便于运维更好的定位系统问题。在SpringMVC中，可以将日志进行分层次拦截。在这种SOA架构中，日志的集中管理，分层次管理，切面管理都是管理日志的方式。特别对于API网关切面管理日志，将API的行为分为HTTP和RPC两种。对于两种行为，又会监控request和response。通过为controller加上@Logging这样的注解去切面拦截日志。这样就可以集中管理API网关的日志了。

2.9 心跳检测

在服务注册中心，系统之间的应用需要时刻保持联系。Master和Slave架构模式中，master作为一个集群中重要的任务分发角色，它需要良好的知道在我的注册中心有哪些slave机器正在良好的待命工作，或是正在繁忙的工作。所以就需要一个心跳检测机制。心跳检测机制在很多系统很多地方都会使用到。比如Dubbo的心跳检测。当集群与集群之间RPC通信的时候，Dubbo会去检测集群下所拥有的组件资源。并且返回最通畅的组件资源返回给请求的组件。此时回源组件会去路由到集群中最近的最通畅的组件。因为Dubbo的服务提供是注册到zk注册中心的，所以注册中心需要和Dubbo之间保持良好的心跳通信。心跳检测同时也用在monitor组件中作为监控系统的一个工具。由于网络是极其不稳定的，系统可能在任意时刻挂掉。心跳检测会去与所请求的资源进行一一握手。系统可以设置一个超时时间，比如在30秒系统没有响应，就判断为系统已经挂掉了。那么这个时候可以通过守护进程的方式去重启某一个组件。并且会向监控平台进行报警。

2.10 高并发设计

系统使用分布式框架就是为了解决服务器瞬间压力过大问题。解决高并发的思路有很多。在系统中采取消息中间价的方式，使用Alibaba的RacketMQ作为消息中间件，实现并发设计。MQ作为中间件承担着消息通知的功能，本系统可以把所有需要发送和接受消息的集群组件去订阅同一个消息。当某些业务，比如下单业务与测评业务不需要同步更新的时候，就可以使用消息中间价。当用户进行下单的时候，会自动给消息中心发一个MQ，并立即返回给用户下单成功了让用户继续操作。订单组件在接受到下单MQ的时候，就会去执行下单的后续操作。哪怕订单组件此时挂掉，也不会影响用户测评的流程。只需要在订单组件处理掉后，回调业务系统即可。使用消息队列可以极大的增加系统的吞吐量。

2.11 实时计算

所谓实时计算，这是近几年来对数据研究应用之后，在数据持久性建模不满足现在对计算的需求，所需要数据流的计算。这种实时计算的应用会设计到方方面面，例如金融服务、网络监控、电信的流量统计等等。在这种数据会源源不断的进入建模中，独立的数据单元可能是相关元组，这些数据会在一个时刻蜂拥而至，这样大量的数据流会持续抵达，由此产生了一个基础性的问题，实时计算。实时计算在某一个时间点会处理少量的数据，然后立即反馈给API层。前端通过对API的数据调用，在WEB页面可以实时的刷新。这样就可以实时的知道数据处理的结果，并判断下一步操作。实时计算经常用来监控一些及时反馈的信息系统。