圆桌论坛：东南亚出海那点事： 1. 出海企业为什么普遍把东南亚当作出海第一站； 2.现在企业的东南亚布局是怎样的（业务重点区域是哪里？什么类型的业务要出海？）； 3. 出海东南亚如何选择IT和网络架构； 4. 遇到IT部署的问题和对业务的影响，未来的规划是怎样的。

11月23日IoT峰会上，Mobike 高级总监李玉峰分享了《IoT运维之路》，并介绍了摩拜在IoT运维路上的创新与改变。
无论做物联网也好，做互联网也好，我们在后端的研发人员，关注最多的是怎么发现问题，解决问题，包括车的问题，用户在什么地方，车出现了问题。骑行过程当中，结费是不是出现了问题，是不是支付出现问题，是不是用户登陆的问题，是不是哪儿崩溃了，但是我们在整体发现问题当中，做了哪些工作呢？



我们经常会有一些这样的感受，为什么每次情况都是业务先发现，客户先发现。还有一个就是我们整体值班是靠感觉的，然后觉得大家的值守，不管是说车整体的链路状态还是我们后台应用的状态，大家在值守的时候，都没有特别好的发现这个问题，大家就觉得这儿有可能出现问题。然后几乎也没有监控，就觉得我们是不是出一些历史性的图表，就可以把这些东西做好。



前期要有监控，大概会分几个方向，首先是业务监控，是不是要加车的状态、链路状态，从开锁到整体的用户支付，到收到订单，整体状态是不是每一个都要埋点。基础监控，硬件的基础设施、应用的基础设施、容器的基础设施上，我们要做哪些事情。链路监控，链路其实就是说整体的一个状态，对于软件层面，或者系统硬件层面，然后每一个地方，是否要采取一些数据，分析一些事情。



后面发现，这三点完全不够，进行了一轮改变，变成了：大数据监控、异常日志监控、Sentry、业务监控dashboard、Event Log、Tracing 全链路监控、Oncall rotation tool。但是这个东西留存度太高了，那我们怎么解决这个问题？进行了发现的优化，因为我们没有自己的机房，也没有自己的硬件设施，我们都是跑在云上，做了服务都拆分了。所以我们大概有两类问题，一类是关于业务，或者关于日志的问题，一类是关于基础信息的问题，那我们有两个节点去完善。



第一点完善，用Prometheus的两个节点，去监控我们容器的状态，监控我们实时下面基础组件的状态。然后我们去收集所有服务器相关的信息，去算一些信息的值，然后去做一些线上实时的分离，让一些硬件工程师去解决问题。



为什么当时会选择用Prometheus来做这一件事情呢？相对于来说，它的生态会相对于成熟，上手比较容易。因为摩拜是一个成立一两年的公司，也许技术沉淀还不是特别高，那我们会用一些比较快，比较容易上手的事情来做这一件事。

通过用Prometheus的Missiles相关的原生基础的节点，来做这样一些事情。因为我们这个Missiles也好，包括Prometheus也好，都是放在Dr容器里面的，但是他们有点像，然后实际测一测，每一个容器不超过0.2个CPU，就可以跑起来。

我们把报警拆出来，自己开发了一些单独的模块来组件。比如说我们报警所有的预置，会接到我们现在所谓报警数据库平台里面去，然后我们大概会预置好多模板中心，包括硬件的模板中心，软件的模板中心，不同的用户支付中心，然后数据库、软件之类不同的模板中心进行匹配。然后我们调动这个组件，会匹配一些策略。比如说也许ABC，三个不同的人，也许我们会在相关的时段，给A报20分，假如说20条短信，假如说一个小时之内。如果这个问题没有得到响应，我们会报给B，如果B还没有响应，我们会报给C。我们会一层级一层级的去报，这是一种调度方法。



其实做容器化的云平台，包括把整个IOT的过程放在云上，其实最大的问题，不是说我们整体业务代码怎么编，怎么写。其实对于我们来说，最难的其实就是说一些监控的调试。因为如果你要做容器化，其实你之前一个单体服务，也可以拆出十几个，甚至几十个这样的服务。



你拆这么多，你怎么发现问题呢？我们做了一些相关的事情。比如说做了一些相关的机制。比如说在每一个容器相关部门，不同属性，不同模块业务之间，相互顺序是什么样子，它的耗时是什么样子，情况是如何的。比如说我们之前调研过两款开源还不错Trace的工具。有一款还是比较流行的，包括国外的案例，做的一个鹰眼这样的系统。然后我们根据开源，做了一些二次开发。我这里大概截了一个Trace的图，大概说明一些问题。

比如说假如是一次简单的访问请求，它由三个模块组成，一个是色块区域，它记录什么？它记录比如说我们用户骑车，从开锁发动请求到解锁，整个完成过程到扣费，整体一个准备是什么样子的，他请求的时间是多少，服务器接受请求时间是多少，完成处理，反馈请求的时间是多少，其中的耗时是多少，也许在这个阶段，会定位一些什么问题。比如说请求之前，你出现了问题，没有发出去，我们服务器没有收到，导致开锁延迟。色块里面，记录了这样一些状态。整体色块组合起来，是整体请求的次数，所有公共的ID叫TraceID，这个可以方便快捷的定位和解决问题。



大概有几个指标，刚才我说了，色块有一系列RPC的构成，一系列的CPC的系列。主要包含什么？主要包含一些信息，比如说CRS，客户端发起的一次请求。它会把这个时间记录下来。然后通过RS的请求时间，就是服务器接收到请求，开始接收时间点，我们就可以算出来，他们的时间是不是有误差，是不是会有网络延时。是不是始终会有问题。SF服务器是否完成了整体处理请求，访问客户端的一个事件。这个SF是否可以跟SR，算出一个处理的时长。服务器完成请求，处理完以后，这个时间段，是不是我们可以算出来，服务器的请求，这是整理数据包的时候，花了多长时间，这个过程，其实可以算出一些现在瓶颈的问题。大概Trace的概念就是这些。

如果我们后端应用通过微服务部署，做了很多容器化相关的事情，其实比较必要的就是效率的问题，比如说我们用监控发现问题，我们怎么快速解决这个问题。比如说你们在骑行过程当中，车子出问题了，车故障了，那我们怎么提升后台统一协调的效率。或者有什么好的解决方式，来做这样的事。我们其实做了一些相关CD的事情。其实摩拜CD的一个演化过程。最开始，我们非常简单的部署。也许我们集群在一个更好的容器上，会有一系列维护的工具，来做一次性的部署。



刚开始部署的时候，也许你lb的请求，你在维护、在升级的时候，你会把lb挂到一个维护页面。你要完成一个更新测试，如果成功了，你会恢复所有的监控。也许失败了，你会把lb取出去，解决问题以后再回来。这样一次性的过程，比较省事，也挺适合你单台机器，十几台机器的状态。但是这种服务器维护窗口时间太长了，所以很早就被弃用了。



然后做一些类似于巩固升级这样的事情，在你的应用，在CD的时候，是不是可以尝试说你们有多组服务，每一组服务有冗余，那我们每一组数据单独摘出来，然后去做一次一次的巩固升级。比如说你刚开始说，也会从lb下载服务，相同的服务。然后让其他几种服务，你这个服务就可以一台一台做我们的升级，当然前期做的时候，你们也要Down time到你的监控服务。一组完成以后，再进行下一组，进行下一组。



这样的好处就是，你整体业务可应用型是百分之百的，几乎没有断裂的过程，那出现问题，唯一不好的地方，也许你会出现两个版本，一个老的版本在实时运行，你现在的版本，其实也是存在的下面会出现一种问题。那我们出现这种问题，这个问题怎么解决，我们参考了一个做云的亚马逊，他在海外一家公司，部署的情况。其实原理很简单，他做的是一次性的部署，相当于是说，他用了AWS的ELV集成代理，他在每一次上线新服务的时候，他会新起一个工具，先做一件图件。比如说他要做用户中心，他会先起一个用户中心这样的组件，把用户中心重置，初始化，一次完整性的发布。

发布完以后，测试通过，整体都测试通过，用户把这个连接指向过去，指过去以后，没有问题，上线了。属于有问题，ERB也会以很快的时间，切回正常的老服务。我们在它的基础之上，做了一些改进，蓝绿部署，现在行业里也比较通用的一种方式，大概做了什么事情？我们现在同时存在两个集成，同时都是提供服务的，也许这组是流量比较大的集群，这组是流量比较小的集群。也许我们会做一些升级，做升级的时候，我们会通过lb，把所有请求都录入到咱们这个执行上去。B的时候，它这个时候不接受请求，它这个时间段，可以释放他之前所有的请求，进行处理。到了一定的时间段，接受请求处理。之前请求处理完之后，进行一个巩固升级。升级完之后，OK，这个没有问题，它的lb就回来，录入到B里面，把它录入上来，指向新的软件技术，再持续部署。只要他部署完善以后，由两者分担，两者同时都能工作，同时存在。

这种架构设计得好，一旦每一个机房如果有充电问题，可以从这个层面，去破除这样的问题。比如说我这个阶段出现问题，我可以把60%的流量，Push到这个机房里面去，然后它承接百分之百。当然前期它有一定的能力承担。他承担了以后，我们做蓝绿部署自己做，做完以后，整体没有问题，然后去接上，告诉他们我们这里已经完成了，再从DNS也好，或者其他CEN这样的平台，把所有的数据都又回来了。大概整体从路由更新到路由探测的一个过程。

把所有软件适配，所有这样的事情，会串在系统集成的流程里面来做CI，这是我大概画了一下我们现在做的CI所有的集成的拓扑图。一个新版本，构建出来，打包成一个可部署的迹象。打包部署完成以后，也许你会通过一些回归测试，可能是第一步回归测试环境，进行回归测试。紧接着这个测试，它会有下跌的UPS这一类设备操作，你测试通过的同时，也许你会打一个值，扔到系统里面去。包括刚才我讲的，一些不同的方式列出去。告诉他，我已经走到回归测试了，走到回归测试以后，然后我们继续适配。



通过UT，通过FT之后，走到了一个最终的回归测试，OK，这个版本已经完全可以上线了，这样时候，打一个最终的版本，给我们的CD。让他确定没有问题了，可以完成整个发布了，这个CI流程已经完结了。如果从每一个环节出现问题，比如说从第一次回归的时候出现问题，或者从适配的时间出现问题。这个流程会被打断，打断以后，然后他们会重新进行测试。

我们整体的链由，因为散热的方式，现在都是集中自动化的。没有什么弯域。这样就会有一些问题，比如说好多环境有监控，每一个人是不是要有一个监控。出现这种控制的问题，怎么搞定。我们就放在这个框架里面，我们用这个框架，管理整体的监控式集群，我们通过DR软件，预定一个模板，它会有基础的配置，权限，每一个业务部门想做CI的时候，会从进项里面拉一个出来。它其实可以注册，或者到你的容器平台进行注册。注册完以后，可以形成一个值，去调动这些业务，完成整体的调度的过程。



也许会有那种情况，怎么做？有一种情况，你使用这个环境的时候，也许会预编一个环境的问题，这个CI流程怎么跑，也许会有一个预编。比如说你要求环境是新的，要求数据是无污染的，也许你会要求新建一个环境，它不会拉原有的，去执行这个过程，它会新建一个环境，从容器池里面拉住一个，构建新的环境，完成一系列平台的测算，到一系列的执行测试到完毕。

然后如果还有一种，比较着急，你CI流程想很快的跑完，不会要求痕迹，特别复杂，特别难受。也许你就会拉一个相对来说，之前存在的环境。你会重新构建，重新生成时间，把这个流程跑完。