架构知识实践与总结（一）

最近换了工作，把最近一两年技术架构的实战总结下。

主要介绍：

1.微服务架构服务发现

2.微服务架构日志追踪

3.异地多活架构部署方案

4.依赖MQ解决数据传输流程

首先介绍下架构实战的业务背景。下面是智能外呼项目部署架构图。

整体介绍

先介绍下“线上服务”部分：

第一步：“电话”接收到音频通过sip协议（https://baike.baidu.com/item/SIP/33921?fromtitle=SIP%E5%8D%8F%E8%AE%AE&fromid=1179615&fr=aladdin），把音频发送给“接入层” 第二步：“接入层”把音频发送给ASR服务，ASR返回文本。 第三步：“接入层”把文本包装成json发送给“中控”，中控负责BaseNLP，NLU、FAQ的服务调度，产生多个意图。 第四步：“决策”服务通过打分，选中一个意图，并调用BOT服务 第五步：BOT服务返回需要返回给用户的信息 第六步：逐层返回，“接入层”会再次调用TTS服务，把文本转换为音频，最终电话的另一头就听到了音频消息 补充：其中“中控”和“决策”是进程内调用。NLU和FAQ都是多个服务，分为系统级和场景级。（所谓的场景就是对话的场景，比如销售房产、销售理财产品、收集信息等）

再介绍下“支撑服务”：

webServer是一个配置平台，让用户配置对话场景、预料、词典、拨打电话、拨打策略等数据 静态服务用来存储音频资源、JS、CSS、图片 日志服务是一个链路日志收集的服务，方便定位问题，抽取日志等。

注册中心：基于ETCD实现了服务发现

数据流程：实现了webServer配置数据到线上服务使用数据的数据流转工作

整体的项目内容介绍完了，是微服务架构一次实践吧。

1.微服务架构服务发现

一开始各个模块都把需要调用的服务地址放到配置文件里，每次修改或者添加了服务需要修改各自的配置文件。而且NLU和BOT的服务是动态变化的。所以修改配置文件特别不灵活。为了解决这个问题，我们基于ETCD做了服务发现。在ETCD中约定一个目录，当服务有新增或者删除的时候，webServer会调用ETCD的接口，修改目录中的配置 ；“中控”watch某个目录，当内容有变的时候，读取服务配置存储到redis中。当请求到达“中控”的时候，“中控”根据请求中的场景ID，获取服务地址、并调用相关的NLU、FAQ服务。

2.微服务架构日志追踪

服务调用链路长了之后，问题定位很麻烦，所以做了“日志服务”。“接入层”接收到请求之后，会根据当前请求生成一个唯一queryID，这个queryID会逐层传递，并在每一个服务中记录下来。各个模块引入一个go的SDK来调用远端的服务写日志。SDK会先把文件保存在本地，在日志达到200条会把一批日志统一发往服务端存储。30天内的日志会存储到ES里，可以根据queryID、phoneID查询出整个日志的链路。访问日志的记录字段

{
    queryID:"",
    moduleID:"",
    fromModule:"",
    toModule:"",
    timestamp:"",
    phoneID:"",
    content:{
    ...
    }
}

3.异地多活架构部署方案

为了提升服务的稳定性，我们对所有的“线上服务”和“支撑服务”和使用的存储都采用了异地双机房部署。先来看一下部署架构图。

拿“线上流程”说明下调用过程，智能DNS，把请求发送到距离更近的LVS，接入层的服务接收到请求后，通过智能DNS，请求同机房的中控服务，中控通过配置中心获取下游服务的vip。此时注意一个细节，获取配置信息的时候，会把多个机房的vip信息都获取到。中控通过本机房的IDC可以区分不同的vip，首先中控会调用同机房服务的vip，在多次重试调用失败后，进行跨机房调用。这样做既减少了网络时延，又保证了服务的可用性。

对于MySQL和Redis的调用都是相同的道理，先调用本机房数据库服务，出现超时或者异常时，调用另外一个机房的数据库服务。对于MySQL和Redis还有一点不同，MySQL和Redis都是采用的一主多从的部署架构，写操作都要到主库执行。其中MySQL的主库采用了双主异步同步数据，通过Keepalived+vip的方式保证高可用。

4.依赖MQ解决数据传输流程

webServer存储用户配置的数据，用户配置的数据想要在“线上服务”生效，需要有一个数据同步的流程，把用户的配置数据输送给NLU、FAQ、BOT、决策等服务。我们暂且把这个流程称为“数据应用”。

在数据应用的过程中需要经过几个环节：

1.从MySQL读原数据，

2.三个脚本做原数据加工

3.加工完的数据需要发送到Redis、ES和给NLU服务的内存。

其中的难点在于每一个流程都是比较耗时的，而且要保证数据的同时生效。

为了解决这两个问题我们使用了以下策略。使用MQ去串联三步流程。具体做法：每一次“数据应用”都生成一个唯一key标识此次数据同步流程，有一个总协调者和三批执行者，协调者开启”数据应用“任务，并标识当前任务执行状态，三批执行者监听状态变化，当执行者接收到某状态的时候，执行自己的任务逻辑，执行完成通知协调者，协调者再去修改任务状态逐步进行，直到所有任务执行完成。如果中间某个环节失败或超时，协调者会针对此任务做自动回滚。只有所有任务都成功了，协调者才会通知线上服务，可以使用最新的数据。为了保证任务重试的时候省略一些重复的步骤，每一步执行完的结果，都会以文件的形式存储到S3上，方便下次快速使用。

总结：

1.微服务通过合理的服务拆分，使业务逻辑更加聚焦，以服务的形式防止业务逻辑、数据操作等复杂性的扩散；解决了代码拷贝的问题；同时也增强了服务的水平扩展能力。但是服务多了之后，也会带来新的问题，服务间调用的互相依赖问题、监控和线上定位问题更加复杂，所以需要做服务治理，具体包括服务的注册与发现，服务自动扩容缩容，服务的监控和日志trace系统等等。同时在设计微服务的时候需要注意几个问题：服务的无状态化，请求的幂等性，负载均衡，服务熔断限流等。

2.在保证服务和数据库高可用时，往往需要服务冗余+限流熔断+故障转移来实现。服务冗余之后就需要考虑负载均衡的问题。数据库冗余之后问题会比较多，因为数据库本身是有状态的，多份数据互相同步就会存在延迟，所以数据库的高可用往往更加复杂。

3.使用MQ除了消峰填谷控制流量外，还可以做异步任务的串联。当然还有很多其他场景可以使用MQ

好了，先总结道这里，希望你看了有所收获。