商城网站技术方案,江西省都昌县建设局网站,网站开发企业培训报名,深圳网站建设公司fantodo本文根据作者在美团点评第21期技术沙龙的分享记录整理而成。 SRE#xff08;Site Reliability Engineering#xff09;是Google于2003年提出的概念#xff0c;将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。 美团点评作为综合性多业务的互联网生活… 本文根据作者在美团点评第21期技术沙龙的分享记录整理而成。 SRESite Reliability Engineering是Google于2003年提出的概念将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。 美团点评作为综合性多业务的互联网生活服务平台覆盖“吃住行游购娱”各个领域SRE就会面临一些特殊的挑战。 业务量的飞速增长机器数量剧增导致人工维护成本增大而交易额的增长对SLA的要求也不断提高。与此同时一些新业务会面临大流量冲击资源调度的挑战也随之增大。业务类型复杂多样、业务模型千差万别对应的技术方案也多种多样因此SRE的整体维护成本大大提高。根据上述挑战我们需要制定相应的解决策略策略原则主要聚焦在以下三点 稳定这也是SRE工作的核心。效率包括云主机交付效率也包括我们自己内部的一些系统效率。成本用最少的机器提供最优质的服务。在此原则的基础上我们开始了对SRE进行的一系列改进。 手工时代 最早期我们前端是4层负载均衡静态资源通过Varnish/Squid缓存动态请求跑在LAMP架构下。这个时候机器很少需要的流程很少也没有区分应用运维、系统运维之类的。运维人员也很少网络、机器和服务都要负责。运维的工作大部分都是靠手工其实当时还没有成型的运维系统现在很多初创公司都是这种架构。 云基础设施 随着业务的发展我们的架构也做出了适当的调整。尤其是在步入移动时代以后移动的流量比重越来越大。接入层不只是Web资源还包含了很多API接口的服务。后端的开发语言也不再局限于PHP根据服务需求引入了Java、Python、C等整个业务架构开始向微服务化变迁。伴随业务架构的变化底层的基础架构也随之改变。最大的变化是2014年中的时候所有的业务已经都跑在了云上如下图所示。 跑在云上的一个好处是把底层主机和网络抽象化相当于云平台将主机创建、网络策略修改等封装到相应的系统内对用户提供统一的平台接口。我们在做维护的时候就能把之前很复杂的流程串连起来。也是在此时SRE团队初步成立我们对整个运维相关的工作做了拆分。云计算部分由美团云负责主要负责主机、网络还有系统相关的SRE对接业务侧负责机器的环境、业务侧的架构优化以及业务侧相关问题的处理。 问题解决方案 接下来介绍一下我们在做云基础建设的过程中遇到的问题和一些解决方案。 如上图所示首先是资源隔离的问题因为这个问题造成过几次故障。我们线上VM的CPU、网卡都是共享的有一次压测的流量很高把主机网卡的带宽基本上都占光了当时的主机大部分都是千兆的很容易打满同宿主机的资源都被它争抢了其它VM上部署的服务的响时间变得很大导致当时我们买单的一个服务买单的VM和压测的VM部署在了同一个宿主上直接挂掉了。 针对这个问题我们做了两点一个是对所有的网络资源都做了隔离针对每个VM作相应的配额另外一个是针对业务特性将宿主集群做了拆分。离线业务它不考虑CPU的竞争各个业务对于所部署服务的具体响应时间不是很关注只要能在一个允许的时间段内把业务跑完就可以了我们把这些服务单独的放在了一个离线集群。在线业务根据不同业务的重要程度又划分成了多个小集群。 第二个问题就是VM打散这个问题初期的时候暴露得并不是很明显当时整个线上的业务还没有做细致的服务化拆分服务都部署在一个大集群内这种情况下即使VM没有打散同一个服务的多个VM在同一个宿主某一个宿主挂掉影响也不是很大。但是随着业务的变化发展再做服务化拆分之后线上的服务基本上没有几百台做成一个大集群的情况都是十几台或者几十台这种小集群。如果我们有一个10台VM的服务其中5台在一个宿主上那么这个宿主一旦挂掉服务整体的承载能力就砍掉了一半风险很高高峰期如果掉一半这个业务就瘫痪不可用了。针对这个问题SRE团队跟云计算的同学做了一个持续了半年多的优化将VM打散率控制到了90%以上最终在同一个宿主上同一个服务不会多于两台VM。 第三个问题完善调度成功率。经过SRE和云计算同学的合作努力现在的成功率已经达到了3个9左右。 云计算基础设施架构 上图是我们云计算基础设施网络相关的架构图可以看到上面是公网的入口流量接入大部分都是走的BGP链路。往下是多机房间的高速专线专线的稳定性经历了线上大规模业务的校验像外卖、团购、酒旅等都是做多机房部署的。 另外就是高冗余的网络架构基本上每个节点都有一个冗余设备能保证在其中一台设备出现问题的时候整个流量不受影响。入口和出口接入了一些自研的组件像MGW参考之前的博客文章“MGW——美团点评高性能四层负载均衡”、NAT等使我们对流量的管控变的更灵活。 美团点评应该是美团云最大的用户美团云能给美团点评带来的收益有完善的API支持、高度定制化资源的隔离、调度机制还有多机房光纤直连以及较高的资源利用率。 运维自动化 随着订单量和机器数的高速增长为了更高效的运维我们不得不往自动化的方向发展。 在自动化演进的过程中我们总结出了自己的一套方法论。 复杂的事情简单化。比如引入云平台基础设备管理都通过云平台的系统来做把底层相关的东西全部封装最终暴露给我们的就是接口或Web界面。简单的事情标准化。如果你想做流程或者自动化没有一个统一标准的话你要考虑的点就会很多。所以我们在主机、域名等资源的命名、系统基础环境、上下线操作等方面出了很多的标准这些标准经历线上的实践打磨最终形成统一的规范。等标准都成型之后我们再引入流程比如创建一些机器我会列出需要的操作然后根据标准来做SOP先流程化再自动化。我们通过代码把手工的工作释放掉最终达到了一个自动化的水准。 这是服务树它包括线上的云主机、服务及服务负责人的映射关系根据不同的层级做一个树形的展示。它将多个周边系统进行打通因为上面有标签通过这个标签能识别唯一的服务。目前我们打通的系统有配制管理系统、容量系统、监控平台等还包括线上主机的登录权限。 另外最新的一个成本核算服务树也已经打通通过服务树的节点只需要进行简单的操作就能看到每个事业群的成本情况。 上图是我们创建机器的一个简单流程首先由技术人员发起流程然后到流程中心流程中心从服务树获取服务的基础信息然后将信息发送到运维平台运维平台根据这些信息去云平台创建机器。之后云平台会返回到运维平台运维平台将创建好的机器加到流程中心提供的服务节点下同时调用配置管理系统对机器进行环境初始化初始化完成后会自动添加基础监控信息。之后调用部署系统对服务进行部署。部署之后服务根据它的服务的标签最终注册到服务治理平台然后就能提供线上服务了。相当于只要技术人员发起整个流程都是能自动完成的。 自动化这块就简单介绍这些下面介绍一下目前的现状。 数据运营 如上图所示现如今公司规模变得很大我们对此做了一些相应的拆分图中红色的部分全部由云平台来负责从最初的接入层到底层的一些基础设施比如机房、网络、主机全部由云平台来封装。中间又拆封了一层这一层是由SRE来负责。 现在流程系统已经做得比较完善了接下来我们新的探索目标就是数据运营这块。首先是故障管理针对线上故障做一个统一管理包括故障发生的时间、起因、负责人根据它的严重程度分为不同的故障等级。我们也会针对故障的后续改进持续跟进优化保证每一个TODO都能落实。 另外一点通过故障平台我们对所有的故障进行汇总系统能根据汇总的信息对不同的故障进行分类也能总结出我们线上不同故障类型的占比进而做一些定点的突破。 在故障管理之后我们又做了一些数据挖掘相关的工作在初期我们运维的数据主要来自于监控平台或者是业务主动上报而在现在这个阶段我们会主动挖掘一些信息比如线上服务的请求量、响应时间等来做一些定向的分析。 职责使命 如上图所示我们的使命从最开始的变更与救火到现在已经逐渐转变为防火与驱动变革。通过数据运营我们能反向的驱动业务。工作核心是稳定性这一点一直没变。 我们可以把运维理解为运营维护运营是指通过经验积累、数据分析推动整体服务质量的改进维护是针对线上的服务还有业务的需求我们能够用专业的技术来满足他们。 下面讲一下在稳定性保障方面的实践。 故障起因实例 首先我们来总结下故障的起因同时举一些例子来说明具体的情况。 ① 变更。美团点评线上服务的日常发版超过300次另外还有一些运维的基础变更包括网络、服务组件等。举个例子线下做变更的时候我们写一个简单的Nginx配置如下图所示。 它和线上写的配置在红色部分的顺序发生了变化如果rewrite的指令在set指令之后可以生效结果符合预期。当我们把rewrite指令前置后break指令会被先执行会结束整个重写过程rewrite之后的set就不执行了导致配置上线之后Nginx找不到后端的服务整个线上的服务就崩溃了。如果做好充分的灰度我们就能及时发现问题并解决但是我们在上线的过程中缺少了灰度过程。事实上标准的SOP标准操作程序应该是上图中的五步但是负责变更的同学想当然也好或者是粗心大意也好在线下测试以后没有发现异常就直接全量上线了最终酿成大祸。 ② 容量。一些大的节假日或者秒杀抢购都会带来大流量异常流量攻击或者爬虫抓取也会带来流量突增。如下图所示这是猫眼发生的一次较大的事故这个故障主要的原因是最底层的、最后端的服务容量不到位在流量发生大的变化的时候它没撑住关键的服务峰值上涨5倍DAU相交元旦前一个历史峰值涨了一倍。 主要是两个问题导致的一个是我们对于大的活动评估不准确还有一个是它的容量不对等。相当于前端的应用评估是可以撑住的但是后面的底层没有撑住前端的流量都打到后端后端撑不住整个服务就挂了。由此我们至少要做到两点第一要知己了解自身能承载的容量情况这点我们可以通过压测或者一些历史数据的参考获取到这个容量。第二要知彼准确知道前端过来的流量究竟有多大可以通过运营和技术的联动在出现一些大的活动或者大的节假日的时候通过他们的容量评估和历史数据做出相应的判断进而做一些容量的准备另外要了解下游系统的容量水位一旦低于本服务的容量我们就要做好限流并且提醒下游服务做相应的容量匹配。 ③ 隐患。隐患主要针对系统设计存在的一些缺陷还有一些组件的交叉调用、关键报警的缺失、链路容量不对称等。这类问题是比较难发现的需要我们深入进行研究。这方面的实例我们可以看下下面这个图没有操作之前它的数据包是沿着绿色的线走的做了操作之后部分数据包就沿着红色走了。变更前后的主要影响是红色链路的数据包session发生了变化因为最初的时候session在IMGW1上在链路发生变化后对于TCP有状态的连接再往后就找不到它后端了数据包没办法发送过去这时候数据就丢失掉了无法连接数据库这个业务就挂掉了。 不过业务层在设计架构之初应该考虑到网络不稳定的情况。针对上面的隐患大概有三个方法。 第一个就是做全链路的演习模拟一个真实的场景经过模拟演习还是多多少少能暴露出来一些问题。我们可以针对这些问题去完善我们的故障预案、修复线上漏洞做演习的时候也能验证我们的报警系统是否正常运转。 第二个是SLA对于服务定一个比较严格的稳定性指标并针对这个指标持续不断的优化。比如我们线上HTTP接入的服务针对accesslog中的状态码和响应时间提炼出一个稳定性指标这对于服务本身的稳定性情况就多了一个可参考数值了。稳定性指标波动服务必然有问题这时候我们就要针对它波动的点进行相应的分析根据分析最终能找到一些隐患。指标这块要做到用真正的数据来反馈出线上的稳定性。 第三个就是做故障的管理每个故障都能找到问题TODO能落实各个故障的经验总结也能共享到多个业务线。 经验总结 事故之前比如标准SOP、容量评估、流量压测的核心就是要防范于未然。事故之中的核心是快速止损查找问题是一个相对来说难度比较大也比较漫长的过程因为这个时间是不可控的。但是如果我们提前有好的应急预案就能达到快速的止损。此外还要有服务的自我保护还有一点沟通也是很重要的。最开始出现问题的时候其实是比较乱的因为大家发现问题都很急很多人都在问原因这时候你问原因是没有用的因为大家大部分是不知道知道的话就能给出解决方案了。所以这时候需要一个完善的沟通机制正确的时间反馈正确的消息反馈的原则是少说表面现象尽量说一些对于问题定位或者是对于止损方面能够有帮助的信息。事故之后像TODO落实、完善预案之类的核心点就是吃一堑长一智相同的问题不能发生第二次。用户体验优化 首先从用户端开始用户在访问我们线上业务的时候流量是从公网到私有云再到Server。公网问题主要有网络劫持、多运营商环境、不可控的公网链路等。对于Server的话主要就是一些传输层的协议或者应用层的协议的问题目前大部分业务交互还是用的HTTP 1.0/1.1其实HTTP这个协议也是需要改进的它不太适合做频繁的业务交互。 针对这些问题我们都做了一些尝试 1. 首先在公网接入这块启用BGP我们现在已经做了自建的BGP网络不用再关心多运营商接入的问题。只需要采用BGP网络数据包在公网传输寻址的时候就可以进行最优的选路了。 2. 面对劫持问题我们尝试了HTTP DNS的方案同时也在尝试Shark就是类似于公网链路加速相当于我在用户的近端部署一个Server在App上嵌入SDK用户通过App发起的请求不用做DNS解析而是先发到Shark参考之前的博客“美团点评移动网络优化实践”上再由Shark与后端服务交互。目前通过多种手段的持续优化劫持问题已经少了很多。 3. 针对业务交互的协议上线了SPDY协议对于频繁交互的业务提升还是很明显的。目前正在测试HTTP 2.0Server端对于HTTP 2.0的支持还存在少量bug努力修复中希望能早日用上。 首先技术上目前我们自动化这块做得比较好还会持续做下一步就是智能化。为什么要智能化呢其实主要面临到一个瓶颈点有些问题是不能通过自动化解决的比如说前面提到自动故障定位它的决策性很强需要很多步的决策并不是通过程序就能直接搞定的。我们现在正在尝试一些AI的算法引入人工智能来做突破。 产品方面我们现在做的所有工具经过线上业务大规模的校验正在往产品化的方向发展希望能把它做成成型的产品放在美团云上能给美团云的用户提供服务。不只服务于我们自己也服务于他人。 最后是技术架构美团点评发展过程中一些疑难问题的解决方案或者针对挑战的经验积累经过线上大规模业务的校验最终能形成一些成熟的方案它能为美团云上的用户提供最前沿的技术参考。 云是大势所趋它能把很多底层的问题封装起来让我们有更多精力去做更重要的事情。 普存2014年加入美团SRE团队现任美团点评应用支持组负责人带领团队为美团外卖、餐饮平台、金融服务等多个业务提供运维支持及业务稳定性保障工作。
