https://v.qq.com/x/page/u05501euzv4.html
基础平台服务基础设施这一块除了我们的设施以外，还有一个基础的服务平台，这样才能非常高效地将我们的业务传递给客户。现在新美大所有的业务都承载在美团云上，有外卖、猫眼、美团、大众点评等等。
上图是基础平台的结构。第一层是物理层，主要包括服务器、网络设备和动力环境。动力环境对于大家来说可能会相对比较陌生，它在整个平台的稳定性方面发挥了比较重要的作用。上一层是IP的控制层，有网络配置、路由表、路由协议。
要把服务稳定地交付给客户，主要是在TCP/UDP的负载均衡层和DNS层上做了很多的稳定性工作。
基础设施
在机房的选型上，基本都是选用T3及以上的标准IDC。要有独立的低压配电系统，比如低压的配电机、UPS的机组、UPS电池、以及柴油发电机。这些都需要针对我们自己模块给到独立的系统，我们才能对机房的稳定性进行把控。同时在空调制冷方面一般会选用2N或者N+1的系统，这样在任何一个机组出现问题的情况下都不会对机房产生任何影响。我们需要有独立的物理空间，按照我们的需求进行定制。
有了高标准的基础设施后依然未必能保证稳定，在此过程中运维也是一个非常重要的步骤。
在运维方面我们有完善的SOP，也就是标准性操作。所有非标准性操作可能都会给机房带来灾难。比如做电力维护时在机房上架标签的时候，标签是否一致，都可能对未来的业务造成影响。同时对IDC的风险评估也做了大量的工作。我们用了机房动力监控，比如UPS的负载、电力的负载以及机房的温度、湿度。并且还做了24小时人工动环的巡检。因为我们有独立的物理空间，所以需要定期做模拟故障演练。
高可用基础服务
MGW Session同步
MGW是我们自研的一套系统，便于与云平台进行整合。同时也提供API，很方便地与业务系统进行打通，作为内部流程的定制化。这样我们在业务交付过程中能高效地完成工作。
我们目前单台服务器在连接Session方面单节点能达到1200万。Session的同步是做单台广播，一旦出现宕机，Session能够在路由层面进行无缝切换，给用户提供无中断的服务。
经过我们自己测试，百万级Session切换的miss率为0。Session采用增量的同步策略，主要通过二层进行同步。一旦有新的Session我们能快速地同步到同集群的其它设备上去，这样在单台机器出现故障的时候能够很从容地进行切换。
我们分别做了单台和多台机器的故障演练。我们用了十个不同的机器通过MGW请求后端的服务来进行文件下载。我们在23:37左右的时候，将第一台MGW关闭。从监控上37分这个时间点来看，业务突发的情况过了之后，它的流量基本为零，整体的十个进程在23:37之后没有波动。同时可能还会面临多台机器同时发生故障的问题，那么这时还能否保证业务交付的持续性呢？
我们在23:43先关掉了第一台MGW，它会把流量切换到第二台蓝色的MGW上面。我们在这个时间点把蓝色这台依然进行模拟的故障将其关闭。大家能够看到第四台的连接数和流量进行了上扬。在23:55的时候第三台进行关闭，所有的流量都无缝迁移到最后一台。在切换的时间点上面，十个压测进程在整体的流量上非常平缓。
在修复了机器之后，我们会对机器进行重新上线。因为机器在上线前没有任何连接，那么上线的时候是否会对业务造成干扰呢？
这是我们故障恢复和扩容的场景。像前面刚刚提到的这些时间段，我们分别演练了三台机器全部进行了一次故障。这个时间段先恢复了第一台MGW，从业务来看基本是没有任何波动的。在1:03左右的时间点，我们分别把剩余的两台也进行了恢复和扩容，从并发下载上来看，1:02到1:03是一个相对平缓的过程。特别需要说明的是上图中有红框框起来的部分，因为我们在压测的时候，它是在做一个4G文件的下载，所以当时的速度都是零。
在我刚刚入行的时候，领导跟我说过一句话，让我印象特别深刻：让一个网站在地球上消失最好的办法就是干掉它的DNS。如果一个机房宕掉了可以通过机房容灾来解决；如果一个区域宕掉了，可以做跨区域的容灾。但DNS出现了故障，那就毫无办法可言。所以可见DNS是我们非常重要的基础服务。通常我们会在一个IDC里面至少部署两台DNS，服务器就会在文件里面配上这两个DNS的IP地址。在迁移到另外一个IDC的时候，由于机房IP地址的唯一性，就要改DNS的地址。
我们采用了基于AnyCast的DNS架构。大家对这个架构其实并不陌生。我们使用最多的DNS服务大概是8.8.8.8。要在不同地方都使用同一个DNS IP，通过在DNS上和内网核心跑一个路由协议，在这上面每台机器有自己管理的DNS IP。业务请求过来的时候它是一个等价路由的形式，它会均分地请求到不同的机器上。也就方便了我们做DNS扩容，而且在做跨机房迁移的时候依然可以用同一个DNS IP。这个主要是在DNS层面做了一层路由的包装，方便了我们整个基础设施架构的部署，简化了整个运维流程。
基础网络质量监控
我一直强调运维的意识决定整个平台的稳定性。在运维过程中如何迅速发现异常、判断问题点，就需要快速直观的监控体系。
因为我们的体量相对比较大，三万+的服务器，几千个机柜，每个机柜都有TOR。这种情况下如何做到对所有整体的网络一目了然，快速响应解决发生的问题呢？
这是我刚刚提到的内网超核，所有跨IDC的层面都需要借助超核进行转发，这上面分别在三个不同的IDC，每个IDC有两组内网核心。
我们会在每一组TOR下面的物理机上布一个Agent，通过Agent监控全网的IP列表。我们建了一个sysop基础设施自动化运维平台，里面记录了基础设施所有资源信息，通过这个平台可以获取到IDC、交换机、服务器所有信息。
最右边是消息告警的平台，根据我们的策略配置一些消息告警。比如两台机器之间有丢包、延时增大等情况，匹配到我们的告警策略之后通知相关人员。
我们收集到的数据是通过InfluxDB进行监控数据的存储，利用Grafana进行展示。
最核心的是我们监控的管理平台Manager。首先我们每台服务器部署的时候会把这个Agent推下去，给Manager发请求，获取到需要监控的IP列表、监控IP的对象、监控IP的数量以及上报的时间。Agent监控生成的数据会上报到Manager模块，通过模块处理后存入InfluxDB。
众所周知，在整个网络架构当中监控南北向的流向是非常容易实现的，因为每个服务器到TOR，TOR到核心，再到外网，这是现在最基本的网络监控。
但是我们需要看到的是东西向流量。两个业务之间的请求，一旦出现异常大家可能第一反应是网络的问题。如何避免这样的问题，同时为我们业务快速定位或缩小问题点，就是这个平台的价值。
通过这个平台给到业务和我们自己，让我们能快速地判断网络是否有问题，或者当服��Ƥ,����务端出现报错的时候，到底是要第一时间排查网络还是DNS，或者是业务服务本身的问题，这样缩小了问题点，让业务快速的定位。因为在电商行业一旦出现问题，影响的时间越长，损失的都是交易金额，所以我们投入了很多的精力来做这一块的工作。我们不怕出现问题，一旦出现问题我们能在最快的时间去解决问题。
这是我们内网监控的第二期架构。第一期完成了东西向流量端到端网络监控，但是还不能直观地监控网络运行状况。按照上图中网络架构，在WJ和DBA的两个超核，每个IDC的内网核心有很多线互联的。两台机器互Ping的时候，出现丢包率。
比如说服务器到TOR，TOR到内网核心可能4条线，到超核是16条、32条线，超核到内网核心又是32条线，排查链路的时候是一个指数级的增长。能否将每一条链路的状况在我们内网的网络拓扑图上面进行展示，这样我们能够第一时间在业务之前发生这个问题。
第二期所做的，就是是能够监测到这32条路径的网络质量。我们通过了解厂商的Hash策略和构造数据，让它人为地走不同链路，拿到从TOR到核心这一段每一秒的ping值和波动来了解到每一段的网络是否有问题。这样能直观地了解到整个网络情况。
我们通过一个地图来展示外网网络质量监控，基于电信、联通、移动三条线路出口分别进行监控。我们主动以1秒钟为频率监控到全国每一个地级市的网络情况。通过这种主动的监控系统探测能够很清晰地知道哪一个区域有问题。
平台发展壮大是源自于用户的选择，我们需要给用户做到更高质量的服务、更好的用户体验。同时这些系统其实在公有云和私有云上复用，我们自己用到什么基础设施、网络条件，给美团云客户也使用同样的服务。
多维资源数据运营
我们会通过监控系统，结合各项数据汇总的指标，针对性的持续优化，最终达到让运维人员更加高效、让基础设施更加的稳定。
在服务器自动化操作方面，我们申请机器的时候走自动化流程，发起、检测有没有系统， CMDB的状况是否正常。如果正常的话，更改为预申请同时部署操作系统，部署之后对主机进行Ping检测。认为没有问题的，最终交付给业务。这些后端都会收集数据，拿到最近30天，流程的总量、成功率、失败率、正在运行的数量以及平均每个流程的耗时来针对性的优化。
同时我们在成本方面也做了一定的考量。比如所有机柜的房间有多少服务器、有多少交换机，这里面有效机柜是多少，针对于每个机柜的电力收集的覆盖率是多少。我们针对这个机柜所承载的业务和服务器的功耗进行智能匹配，来提高机柜的有效率。机柜的有效率上升了，在IDC平均业务量的租用成本就会降低，这也是数据化运营的方向。一个是提高我们的稳定性，一个需要降低整体的成本。
现在除了有数据以外，我们更多强调监控的可视化。
我们在机房都有类似于探头来监控环境，比如一些变更。包括除了机房的动力环境以外，我们自己来监控机房的温度、湿度是否达标。假如机房一个机器或者空调出现了问题，它并不一定会告诉你。当机房不可控的时候我们再发现，可能整个机房就死掉了，所以这里会有一个提前的预警，包括跟机房建立一个长效的沟通机制。我们在IDC层面，每一个Q进行一次巡检。做一个动力环境的巡检，检查基础设施的利用率是否有超标、是否有风险来完善整个风险的评估体系。