Idc

随着5G、云计算等技术的倒退，网络环境更加简单，平安问题一直交错。天翼云将通过两期文章，详尽讲述以后云环境下普遍存在的几大平安威逼以及天翼云是如何一一击破它们的。视频连线、云端答问、云上散会......“云”成为往年两会中一道亮丽的风景线。随同着两会的全面上云，保障两会的通信及信息安全变得更为重要，而云平安作为网络安全家族中的一位新成员，也在两会信息安全体系中显露头角。 另一方面，从天而降的疫情促使线上行为时长激增，各行各业都在将业务向云端迁徙，一时间“云”成为人们赖以生存的重要根底。然而，在互联网的世界里，网络攻防两端永远在博弈，此消彼长没有完结的一天。因此，云平安在当今成为重中之重。 云平安与传统IDC平安到底有何不同？在传统IDC（互联网数据中心）中，面临的网络威逼次要分为两局部，内部威逼和外部威逼。内部威逼的常见类型有DDoS攻打，木马、蠕虫、病毒入侵，非受权拜访，SQL注入、网络扫描、监听等。如果把IDC类比为一个五星级大酒店，那么内部威逼就相当于想要侵入酒店外部的窃贼、匪徒，他们千方百计进入酒店外部，窃取客户的各类财产。  与内部威逼不同，外部威逼相当于在酒店外部产生了盗窃事件，攻打方可能是某个图谋不轨的内部人员或客人，也可能是内部威逼浸透进来之后的二次扩散。它次要包含内网IP、ARP坑骗，非法终端接入、越权拜访&操作、要害信息泄密等。相比传统IDC平安，云计算环境下的平安威逼在原有威逼的根底之上，又因为虚拟化的技术新增了一些新型的威逼类型。 云计算畛域十二大平安威逼现在，越来越多的企业将数据和应用程序转移到云上，这一趋势无疑将会带来更多的网络安全威逼，而最小化云端平安威逼的第一步，就是认清这些平安威逼。CSA云平安联盟针对云上的环境，定义了十二大平安威逼，根本涵盖了云计算环境下面临的次要平安威逼。 新常态减速了企业数字化转型的步调，催生了更多传统企业上云的需要。云计算在国内的前景广大，但仍然须要解决几大痛点，包含升高资源隔离、明确网络边界、解决平安威逼等主观挑战。保障租户业务间断不中断，保障运维近程可管控，保证数据窃密不扩散是“天翼云，平安云”的劣势所在。

当开发基于物联网的产品时，测试被认为是该过程中最重要的方面之一。然而，鉴于物联网测试过程的复杂性，咱们当初曾经看到了自动化的呈现。 什么是物联网测试? IoT测试次要是执行QA测试的实际，有助于验证IoT设施的性能、性能和安全性。这是因为每个物联网设施都通过互联网将数据从一个对象传输到另一个对象。此外，验证您的物联网设施是否能够无线传输敏感信息至关重要。这就是为什么明天许多胜利的物联网企业都依赖物联网自动化、浸透和性能测试工具，以便在任何缺点达到消费者之前就能够检测到它。 物联网自动化测试的益处 物联网自动化测试无疑是有帮忙的。为了帮忙您理解其后劲，让咱们从概述IoT自动化测试的一些次要劣势开始： 速度 虚拟化是物联网自动化测试过程的一个要害方面，可帮忙开发团队辨认妨碍物联网设置有效性和效率的问题。此外，自动化有助于在各种设施上同时执行测试。总而言之，这个过程有利于物联网设施的一致性和疾速测试。 进步生产力 在此过程中取得的另一个益处是通过将运行时剖析与实时测试相结合。这使得跟踪谬误、生成自动化测试脚本和执行回归测试等变得更加容易。 全面笼罩 自动化不仅使测试物联网设施以及相干软件、不同应用程序版本等变得更容易、更实惠。它还能够为各种测试过程开发易于扩大的虚构实验室。 物联网自动化测试的挑战 当初，让咱们相熟一下物联网自动化测试路线上的挑战： 数据量 物联网设施必须解决大量数据;事实上，数据量如此之大，一些公司会发现自己难以正确治理和利用这些丰盛的数据。通过弱小的网络连接能够轻松解决这一非凡挑战。 平安 能够了解的是，物联网背景下最紧迫的问题之一是安全性。为了确保一流的安全性，必须对物联网设施进行密集和全方位的平安测试。哦，别忘了施行最新的安全措施。 实时数据可用性 物联网的全副意义在于硬件和软件之间的实时数据传输，这种替换常常受到带宽问题和网络故障的妨碍。因而，请务必依据不同的理论场景测试网络性能。 物联网自动化测试的要害策略 最初，看一下要害策略： 定期测试 测试团队最好记住，确保自动化物联网测试胜利的要害是在公布更新后对软件进行定期测试、补丁等。当咱们议论更新时，请记住，不足定期更新可能会对网络安全形成严重威胁。 网络虚拟化 只管物联网设施高度依赖于网络可用性，但事实依然是网络测试可能十分具备挑战性，尤其是在没有从新创立实在测试环境的状况下。这就是为什么倡议进行网络虚拟化测试的起因，因为它们容许公司提前可视化预期的网络情况并解决可能呈现的问题(如果有的话)。 论断 物联网测试尽管有点简单，但对于实现IT基础设施和网络之间的同步无疑是必不可少的。因而，质量保证团队也必须认真留神整个测试过程的这一方面。

对于建站人员来说，很明确网站对空间有什么样的需要，并且晓得在当初这个互联网时代呈现了很多不同品种的网站，而不同品种的网站须要不同建站空间作为撑持，其中作为建站空间之一的海内服务器受到了很多建站人员的举荐。然而海内主机虽好，但也不能满足所有外贸企业建站需要，那么海内服务器适宜什么样的外贸企业应用?上面就和小编一起来理解。 图片海内服务器指的是位于海内数据中心的服务器。其中我国的香港、澳门也属于海内，所以其服务器也称之为海内服务器，也就是说除了大陆数据中心的服务器外，其余地区数据中心的服务器都可称之为海内服务器。 图片海内服务器适宜什么样的外贸企业应用? 图片1、外贸企业建站应用 外贸企业服务器的是海内用户，为了可能让海内用户更快更稳固的拜访网站，企业会必须抉择离用户比拟近的数据中心的服务器作为建站，所以须要海内服务器作为建站空间。 图片2、对网站空间资源要求比拟大 企业网站须要向服务器上上传很多文件，并且随着企业一直的倒退，还会一直的上传更多的文件，所以企业建站对空间的资源要求比拟高，而服务器的资源就比拟多，能满足外贸企业建站的需要。 图片3、对网站空间性能要求高 外贸企业网站如果想要很好的运行，那就必须满足疾速的访问速度、良好的稳定性和高效的安全性。而服务器是独立的，领有十分高的性能，能满足访问速度、稳定性和安全性。

7月21日，寰球权威咨询机构 IDC 公布《中国视频云市场跟踪（2020下半年）》报告。报告显示，2020下半年，中国视频云市场规模达到38.1亿美元，同比增长达到45.7%，其中视频云解决方案市场最为亮眼，市场规模达到近7亿美元，同比增长达到75%以上。百度智能云在解决方案市场排名第三；而在视频云总体市场上，则位居前四。 \IDC 钻研发现，在线音视频互动娱乐、电商平台直播带货、在线教育大小班课等三大场景仍然是驱动下半年市场增长的外围能源。而来自广电传媒、医疗、金融等传统行业的需要日益清晰，区域视频云服务平台建设步调放慢，成为下半年市场增长的亮点。 报告进一步提到，百度智能云公布智能视频云3.0，在 AI-Native 架构下提供更全面的平台与场景化解决方案，聚焦互娱、传媒、工业、政府、交通、教育、医疗、金融等垂直行业，提供具备智能化特色的视频创作散发平台和视联网感知平台以及云边端一体化的残缺 PaaS+ 解决方案。百度智能视频云3.0曾经在泛媒体、泛互联网利用、泛产业等三大场景中迅速落地，打造了泛滥利用案例。 在泛媒体场景方面，百度智能云先后携手央视网、人民日报等央媒党媒，以及浙江广电等领有区域影响力的支流媒体，利用当先的云计算、AI、大数据等科技，摸索智能媒资治理、智能内容生产与智慧媒体经营，助推媒体产业转型降级。而在泛互联网利用场景中，百度智能云联结杭州星犀科技，将智能视频云 PaaS 能力与云犀直播 SaaS 利用联合，破解批发直播搭建慢、经营资源少等电商痛点。在泛产业场景中，百度智能云携手升哲科技整合 AI、视联网及物联网科技，助力宜昌市点军区在城市治理、社会关心、消防安全、环境监测等方面为民生带来更多便捷、智能的服务。 对于视频云市场的下一个增长低潮，IDC 中国行业云服务钻研经理魏云峰示意，视频场景正在向高清化、交互式、沉迷式演进；非视频场景则在向视频化演进。这两大能源将驱动视频云市场继续高速增长，甚至发明出全新的“超视频化时代”。 百度智能云将来将依靠云智一体化、产品平台化、利用场景化的智能视频云3.0，联合长期丰盛的业务实际，携手更多生态搭档，助力各行业落地更残缺、更优质、更低门槛的视频云解决方案，为业务倒退赋能。 百度AI开发者社区https://ai.baidu.com/forum ，为全国各地开发者提供一个交换、分享、答疑解惑的平台，让开发者在研发路上不再“孤军奋战”，通过一直地交换与探讨找出更好的技术解决方案。如果你想尝试各种人工智能技术、开辟利用场景，赶快退出百度AI社区，你对 AI 的所有畅想，在这里都能够实现！ 扫描下方二维码，增加小助手微信「京东卡、小度定制周边、神秘礼盒、行李箱」等更多福利你来拿~

随着寰球网络经济的迅猛发展，数据中心逐渐成为了社会倒退的外围能源。需要的日益简单，建设模式也迎来泛滥的挑战。为满足机房的高效制冷、节能环保、低碳经济等低劣属性，图扑软件（Hightopo）为此退出3D可视化模块，以三维平面模式展现进去，进一步实现对泛滥子系统集中调配治理。 满足实时在线查看，操作便捷、直观展现，升高了机房治理难度，加重机房运维的压力。本文将介绍使用图扑软件（Hightopo）丰盛的 2/3D 组态 搭建出的一个3D可视化集装箱数据中心。 容量治理可视化 在2D面板中能够查看到该环境下根底设施资源应用状况，能同时采集上万条数据，可兼顾空间、配电、硬件等多维度因素，掌控机房全局。 资产治理可视化 传统表格局治理能用性差、效率低下，不适用于资产量宏大或品种繁多的数据中心。采纳3D数据可视化技术，可对资产治理进行实时数据和查问，鼠标点在设施上即可查问设施信息。可视化分级浏览，满足上万条数据进行资产数据自动更新，晋升数据可用性和使用率。 l 监测蓄冷罐：在机房产生故障时是否失常启动的放冷模式、充冷模式和保冷模式； l 监测收缩罐：是否失常运作，确保水压均衡，机房失常运作； l 监测冷却塔：是否失常进行循环水冷却等。 将虚构资产事实资产一一对应，资产治理3D可视化运维变得更为直观。实现多个机房集中监控，历史查问，远程管理，预警告警、定位于一体的智慧机房。 管线可视化 在可视化环境下能分明查看到管线全景视图，被动预警及时告知电力布局或输、发、变电环节的不合规状况。辅助运维人员科学决策，全面认知，一改来日“关门看报告、拍脑袋定计划”的景象。 3D温度云图 数据中心“喜冷怕热”，随着计算规模逐渐增大，热量也会逐步增大。采纳数据可视化系统还原场景，通过自动检测采集温湿度数据，进而呈现出所有的热源散布，提供统计和预警。鼠标点选设施可查看子设施实时温湿度数据，由2D面板承载数据。 采纳3D温度云图，能够较大水平上解决机房温湿度问题，杜绝被动“热处理”，实时感知外部温湿度状况，无效保障机房失常的运行。 数据中心是信息化部署建设外围基础设施的新秀，图扑软件（Hightopo）智慧机房以智能化、模块化、标准化的理念，通过24小时实时监控，即便运维人员再少，也能及时发现机房安全隐患，保障机房业务的连续性。 数据中心作为通信网络的重要“心脏”，选用图扑软件（Hightopo）三维仿真集装箱数据中心监控平台，扭转数据孤岛景象，将数据全面集成，为数据中心实现扁平化、集约化、一体化施展弱小作用。

近日，IDC公布以太网交换机和路由器季度追踪报告，依据报告数据显示，2020年第三季度寰球以太网交换机市场支出达到74.5亿美元，同比增长1.9%，其中中国市场同比增长14.7%。 IDC数据中心和多云网络钻研副总裁Brad Casemore示意认为，交换机市场的增长次要得益于超大规模数据中心厂商为满足市场对其服务一直增长的需要，而对容量进行的一直减少。由此可见，交换机市场蕴藏着微小的发展潜力，而随着数据中心容量的一直减少，势必会进一步推动高带宽数据中心网络的持续增长。 40G到100G再到400G，新华三的翻新基因与生俱来 作为数字化解决方案领导厂商，新华三在以太网交换机市场有着深厚的技术和教训积攒，无论是过来的40G交换机还是以后支流的100G交换机产品，乃至新华三往年刚刚推出的400G交换机产品，在市场都始终放弃领先地位。从2020年4月份开始，新华三曾经在国内各大OTT公司部署最新公布的400G交换机，实现产品商用。而在618、双十一期间，新华三400G交换机的产品可靠性也失去了测验，扛住了再创新高的流量洗礼。 新华三团体交换机产品线产品管理部部长陈伯超提到，新华三之所以可能始终放弃市场当先，是因为新华三时刻放弃有一份使命感，且肩负了泛滥客户的心愿，此外新华三还有着与生俱来的的翻新基因。而这份翻新在刚刚公布的新华三400G交换机产品中尤为凸显! 强烈竞争下，新华三400G交换机信念满满! 理解交换机市场的用户都分明，新华三并非400G交换机市场的惟一玩家。面对强烈的市场竞争，新华三团体交换机产品线总经理乔剡示意，新华三始终砥砺前行，通过不断创新来解决用户在产品服务层面的痛点问题，从而帮忙用户晋升网络经营效率，升高整体部署老本。而最新推出的400G交换机次要是针对广域网大带宽客户，通过技术创新来满足数据中心客户日益增长的带宽需要，以及无效升高部署和运维老本。 依据乔剡介绍，相比友商的400G交换机产品，新华三的400G交换机有着以下几点劣势： ●硬件层面，很多友商的400G产品是新的平台，与先前老旧产品互相割裂。而新华三公布的S12500R是面向400G进行的平滑演进，最大限度爱护用户投资。此外，新华三的技术架构使产品更具性价比; ●软件层面，新华三有成熟的AD-NET解决方案，此外还包含广域网以及广域网的流量调度，通过SDN的染指优化跨网域的流量带宽，实现降本增效。 ●零碎层面，新华三最新的400G交换机内置了全新的网络操作系统Comware V9。相比于之前的Comware V7，最新的Comware V9版本在站长交易性能上有了较大晋升，更像安卓或IOS零碎，其生态齐全凋谢，可能运行在嵌入式设施上。 除了上述独特的技术劣势，新华三对400G交换机产品的信念还来源于宽泛的用户群体，这其中就囊括了目前国内对网络需要最高且引领技术趋势的一些客户。 产品翻新到颠覆市场 如果说新华三的交换机从40G到100G是一种翻新，那从100G到400G则是对交换机市场的一场颠覆。如陈伯超所讲，以后400G正站在时代的拐点，趁着新基建的东风，智能制作、人工智能以及智慧城市建设，为传统业务带来了智慧化，而这也引发了网络的飞速改革。 陈伯超示意，将来新华三要解决的不只是行业客户的须要，而会更多的承当起助推数字经济转型的重要角色。当越来越多的客户须要性能更高的根底设施时，新华三能适时推出这样的产品，那么咱们便是最棒的!

摘要：用实际案例带你把握云连贯CC如何实现跨区域多VPC与线下IDC Server互联。【背景】以后在华为云华南、华东、香港region均部署了业务，同时在华南region通过云专线与线下IDC买通，线下IDC有须要提供服务的IDC Server，想实现各region间失常互通以及各region与华南IDC Server数据的交互。 【拓扑剖析】 【前提条件】确保安全组/网络ACL/安全设备等已放通对应端口、地址、网段 【操作步骤】一、创立各region的实例（VPC）1）登录控制台，创立对应region的VPC 2）全副创立实现后如下 3）依照拓扑布局，为各VPC内增加对应的ECS（共计4台） 以及线下IDC通过云专线接入的服务器一台（10.32.0.32） 4）在退出云连贯之前，对各region内VPC的ECS（且ECS未购买EIP）进行连通性测试，均不可达 二、将这些region的VPC通过云连贯买通1）进入控制台，创立云连贯 2）云连贯创立好后，须要加载网络实例，将各实例买通（此处的实例指的是VPC） 3）将实例加载到云连贯 参数阐明： 区域：您将要增加的实例所在的区域（region） VPC：您将要增加的实例名（当同一region有多个实例时，须要增加屡次） VPC CIDRs：您将要增加的实例对应的子网信息（可全选也可抉择局部子网，局部有平安要求的子网能够不增加，这样起到了平安爱护的作用） 4）持续加载，直到所有的实例增加实现，此时也能够看到增加好后生成的路由信息 5）购买带宽包，调配域间带宽 调配实现后，云连贯创立实现。 三、后果验证1）通过登录香港的ECS，进行同region不同vpc测试，不同region不同vpc测试，以及各regionECS到华南IDC Server测试，发现已全副可达，后续业务可失常交互。 【后果验证截图中，间接ping了各服务的域名，提前做了解析，更不便辨认】 点击关注，第一工夫理解华为云陈腐技术~

11月4日，蚂蚁金服联合国际数据公司IDC在第二十七届中国国际金融展上发布《移动金融科技助力新时代金融机构转型升级——中国金融级移动应用开发平台白皮书》（以下简称《白皮书》）。《白皮书》指出，中国⾦融市场正在经历剧烈的变⾰，⾦融业务呈现出移动化、智能化、场景化态势，移动应⽤需求大量爆发，推动着⾦融机构加速执⾏移动优先战略。 移动端成金融机构零售转型的重要载体，战略地位日益凸显《白皮书》认为，随着IT领域的新兴技术⾰命，企业数字化转型浪潮正在不断重塑各⾏各业的运⾏格局和发展⻛貌。以金融业为例，利率市场化、⾦融脱媒以及互联⽹跨界竞争等多重因素动摇了传统金融机构的盈利基础，使中国金融市场正在自内而外地发生巨大变革。 在此背景下，金融机构纷纷开启零售转型战略，以金融科技创新为抓手，为企业发展赋能。移动端作为金融机构重要的对外渠道之一，已成为零售转型的重要载体。利用优质的移动端设计提供精细化服务，吸引更多的个人客户长期驻留，是金融机构应对市场挑战、实现长期发展的必然选择，移动优先战略成为金融机构面向未来的发展共识。 《白皮书》显示，在⾦融科技的推动下，⼀⼤批传统线下业务通过技术创新转移⾄线上运营，⽤⼾不再受到银⾏服务时间和空间的限制，随时随地的享受移动端带来的便捷性，⽤⼾体验获得了⾰命性提升；保险公司⼤⼒拓展移动渠道，通过保险移动展业，以更加便捷⾼效地⽅式实现全业务触点的销售及管理，降低获客成本；证券企业则重点利⽤新技术提升信息和数据处理的时效性，满⾜客⼾对移动端⾏情资讯的传递和承载需求。 一站式移动开发平台mPaaS，助力金融机构移动优先战略落地《白皮书》指出，金融业务的移动化、场景化、智能化趋势，推动金融移动应用需求的爆发性增长，对金融机构围绕移动端的业务开发和保障能力提出极大挑战。金融机构迫切需要引入新一代移动设计开发思想，利用先进的移动应用开发平台实现在开发、运维、管理以及快速迭代方面的一系列变革。 蚂蚁金服移动金融技术总监祁晓龙认为，金融级移动应用开发平台应具备统一的开发框架，拥有强大的技术整合和集成能力，有助于打造基于移动中台的能力输出，满足金融行业对移动开发平台技术先进性、安全合规性和高稳定性、高可用性等一系列特殊要求。 基于对金融市场的洞察和全新用户行为的理解，蚂蚁金服移动开发平台mPaaS借助统一的客户端开发框架和蚂蚁特有的金融级移动中台能力，有效地加快研发效率，增加对APP动态管控及千人千面的数字化运营能力。同时基于“后台连接服务”构建与服务端的数据、多媒体传输通道，确保全链路的稳定、安全和高效。 移动端创新技术方面，mPaaS提供智能推荐、语音识别、图像识别、生物识别、小程序等能力，改善产品体验，助力业务创新。 安全合规方面，mPaaS提供IPv6、国密、容灾等特色行业能力，满足监管合规要求。同时辅以应用加固、安全键盘、IFAA生物认证及数据加密能力，充分保障数据在客户端本地、传输过程中的安全性。 目前mPaaS已服务中国农业银行、广发银行，华夏银行，西安银行、国寿保险、财通证券等众多B端客户，为国内国际用户都带来优质的移动端体验。 蚂蚁金服全栈式金融科技体系，助力金融业全域数字化转型科技是面向未来的核心驱动力。基于对未来的洞察和蚂蚁金融科技开放的实践深耕，蚂蚁金服在金融领域构建了一个自底向上的全栈式金融科技体系，从具有金融级别支撑能力的分布式计算平台等底层技术，到以人工智能、区块链等为代表的应用技术，再到智能风控、生物核身等金融级专有技术，以及一站式的移动开发平台mPaaS，形成完整的技术堆栈，助力金融机构快速打造新一代超级移动金融平台与大数据智能运营体系，推动金融机构转型升级。 据悉，包括蚂蚁金服移动开发平台mPaaS、分布式中间件SOFAStack、分布式关系数据库OceanBase等在内的产品和解决方案正通过阿里云新金融统一对外输出，服务各种类型的金融机构。而在未来，还会有越来越多的蚂蚁金服技术产品通过阿里云新金融对外输出。在第二十七届中国国际金融展上，这些世界级的解决方案进行了亮相，并吸引了诸多关注。

一般方案：简单的基于DB方案： DB1生成的ID%4=1，...，DB3的ID%4=3；异地多活：要求跨IDC ID不重复。因为有每个集群IDC标识不同，可保证id不重。性能 解决DB性能问题：一次从DB获取N个ID，N可配置，对应DB的操作就两个：query当前IDupdate current_id = current_id + 4*N where current_id=id_queried然后在内存中记录4*N个ID中计算出模4为DB_index的N个ID，放在内存list中。casice可水平扩展：每个ice会访问集群内的4个DBs，实现对DB访问的负载均衡；高可用：合理配置N，单个DB可以满足足够高的ID QPS需求，因此，即使4个DB中的3个都挂了，单个DB完全能够撑住任意高的ID QPS，服务还是OK的；接口低延迟：调用方获取ID是从内存list中直接获取，list有最低长度校验，低于该值，将异步触发从DB中获取ID；预加载：启动时，ice会加载30w个ID到内存list中，以保证所有DB全挂时，按照当前专快订单QPS峰值500计算，内存list还能支撑30分钟的ID使用量；降级：当所有DB全挂，并且内存list里面的ID全部用光时，将会降级到timestamp方案；由于timestamp位数的限制，我们牺牲QPS容量，来提供可用年限，单个ice实例QPS容量为8k，并且单个集群最多只能有16个ice实例，思考：64位中重复少，比如若时间，每s都一样浪费了41位。数据生成快（zk估计不会生成这么快，批量生成），有持久。载入内存。

背景近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？需求描述对于HIDS产品，我们安全部门的产品经理提出了以下需求：满足50W-100W服务器量级的IDC规模。部署在高并发服务器生产环境，要求Agent低性能低损耗。广泛的部署兼容性。偏向应用层和用户态入侵检测（可以和内核态检测部分解耦）。针对利用主机Agent排查漏洞的最急需场景提供基本的能力，可以实现海量环境下快速查找系统漏洞。Agent跟Server的配置下发通道安全。配置信息读取写入需要鉴权。配置变更历史记录。Agent插件具备自更新功能。分析需求首先，服务器业务进程优先级高，HIDS Agent进程自己可以终止，但不能影响宿主机的主要业务，这是第一要点，那么业务需要具备熔断功能，并具备自我恢复能力。其次，进程保活、维持心跳、实时获取新指令能力，百万台Agent的全量控制时间一定要短。举个极端的例子，当Agent出现紧急情况，需要全量停止时，那么全量停止的命令下发，需要在1-2分钟内完成，甚至30秒、20秒内完成。这些将会是很大的技术挑战。还有对配置动态更新，日志级别控制，细分精确控制到每个Agent上的每个HIDS子进程，能自由地控制每个进程的启停，每个Agent的参数，也能精确的感知每台Agent的上线、下线情况。同时，Agent本身是安全Agent，安全的因素也要考虑进去，包括通信通道的安全性，配置管理的安全性等等。最后，服务端也要有一致性保障、可用性保障，对于大量Agent的管理，必须能实现任务分摊，并行处理任务，且保证数据的一致性。考虑到公司规模不断地扩大，业务不断地增多，特别是美团和大众点评合并后，面对的各种操作系统问题，产品还要具备良好的兼容性、可维护性等。总结下来，产品架构要符合以下特性：集群高可用。分布式，去中心化。配置一致性，配置多版本可追溯。分治与汇总。兼容部署各种Linux 服务器，只维护一个版本。节省资源，占用较少的CPU、内存。精确的熔断限流。服务器数量规模达到百万级的集群负载能力。技术难点在列出产品需要实现的功能点、技术点后，再来分析下遇到的技术挑战，包括不限于以下几点：资源限制，较小的CPU、内存。五十万甚至一百万台服务器的Agent处理控制问题。量级大了后，集群控制带来的控制效率，响应延迟，数据一致性问题。量级大了后，数据传输对整个服务器内网带来的流量冲击问题。量级大了后，运行环境更复杂，Agent异常表现的感知问题。量级大了后，业务日志、程序运行日志的传输、存储问题，被监控业务访问量突增带来监控数据联动突增，对内网带宽，存储集群的爆发压力问题。我们可以看到，技术难点几乎都是服务器到达一定量级带来的，对于大量的服务，集群分布式是业界常见的解决方案。架构设计与技术选型对于管理Agent的服务端来说，要实现高可用、容灾设计，那么一定要做多机房部署，就一定会遇到数据一致性问题。那么数据的存储，就要考虑分布式存储组件。 分布式数据存储中，存在一个定理叫CAP定理：CAP的解释关于CAP定理，分为以下三点：一致性（Consistency）：分布式数据库的数据保持一致。可用性（Availability）：任何一个节点宕机，其他节点可以继续对外提供服务。分区容错性（网络分区）Partition Tolerance：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以添加一台机器，然后从其他正常的机器把备份的数据同步过来。根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了Consistency。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了Availability。除非两个节点可以互相通信，才能既保证Consistency又保证Availability，这又会导致丧失Partition Tolerance。参见：CAP TheoremCAP的选择为了容灾上设计，集群节点的部署，会选择的异地多机房，所以 「Partition tolerance」是不可能避免的。那么可选的是 AP 与 CP。在HIDS集群的场景里，各个Agent对集群持续可用性没有非常强的要求，在短暂时间内，是可以出现异常，出现无法通讯的情况。但最终状态必须要一致，不能存在集群下发关停指令，而出现个别Agent不听从集群控制的情况出现。所以，我们需要一个满足 CP 的产品。满足CP的产品选择在开源社区中，比较出名的几款满足CP的产品，比如etcd、ZooKeeper、Consul等。我们需要根据几款产品的特点，根据我们需求来选择符合我们需求的产品。插一句，网上很多人说Consul是AP产品，这是个错误的描述。既然Consul支持分布式部署，那么一定会出现「网络分区」的问题， 那么一定要支持「Partition tolerance」。另外，在consul的官网上自己也提到了这点 Consul uses a CP architecture, favoring consistency over availability. Consul is opinionated in its usage while Serf is a more flexible and general purpose tool. In CAP terms, Consul uses a CP architecture, favoring consistency over availability. Serf is an AP system and sacrifices consistency for availability. This means Consul cannot operate if the central servers cannot form a quorum while Serf will continue to function under almost all circumstances.etcd、ZooKeeper、Consul对比 借用etcd官网上etcd与ZooKeeper和Consul的比较图。在我们HIDS Agent的需求中，除了基本的服务发现 、配置同步 、配置多版本控制 、变更通知等基本需求外，我们还有基于产品安全性上的考虑，比如传输通道加密、用户权限控制、角色管理、基于Key的权限设定等，这点 etcd比较符合我们要求。很多大型公司都在使用，比如Kubernetes、AWS、OpenStack、Azure、Google Cloud、Huawei Cloud等，并且etcd的社区支持非常好。基于这几点因素，我们选择etcd作为HIDS的分布式集群管理。选择etcd对于etcd在项目中的应用，我们分别使用不同的API接口实现对应的业务需求，按照业务划分如下：Watch机制来实现配置变更下发，任务下发的实时获取机制。脑裂问题在etcd中不存在，etcd集群的选举，只有投票达到 N/2+1 以上，才会选做Leader，来保证数据一致性。另外一个网络分区的Member节点将无主。语言亲和性，也是Golang开发的，Client SDK库稳定可用。Key存储的数据结构支持范围性的Key操作。User、Role权限设定不同读写权限，来控制Key操作，避免其他客户端修改其他Key的信息。TLS来保证通道信息传递安全。Txn分布式事务API配合Compare API来确定主机上线的Key唯一性。Lease租约机制，过期Key释放，更好的感知主机下线信息。etcd底层Key的存储为BTree结构，查找时间复杂度为O（㏒n），百万级甚至千万级Key的查找耗时区别不大。etcd Key的设计前缀按角色设定：Server配置下发使用 /hids/server/config/{hostname}/master。Agent注册上线使用 /hids/agent/master/{hostname}。Plugin配置获取使用 /hids/agent/config/{hostname}/plugin/ID/conf_name。Server Watch /hids/server/config/{hostname}/master，实现Agent主机上线的瞬间感知。Agent Watch /hids/server/config/{hostname}/来获取配置变更，任务下发。Agent注册的Key带有Lease Id，并启用keepalive，下线后瞬间感知。 （异常下线，会有1/3的keepalive时间延迟）关于Key的权限，根据不同前缀，设定不同Role权限。赋值给不同的User，来实现对Key的权限控制。etcd集群管理在etcd节点容灾考虑，考虑DNS故障时，节点会选择部署在多个城市，多个机房，以我们服务器机房选择来看，在大部分机房都有一个节点，综合承载需求，我们选择了N台服务器部署在个别重要机房，来满足负载、容灾需求。但对于etcd这种分布式一致性强的组件来说，每个写操作都需要N/2-1的节点确认变更，才会将写请求写入数据库中，再同步到各个节点，那么意味着节点越多，需要确认的网络请求越多，耗时越多，反而会影响集群节点性能。这点，我们后续将提升单个服务器性能，以及牺牲部分容灾性来提升集群处理速度。客户端填写的IP列表，包含域名、IP。IP用来规避DNS故障，域名用来做Member节点更新。最好不要使用Discover方案，避免对内网DNS服务器产生较大压力。同时，在配置etcd节点的地址时，也要考虑到内网DNS故障的场景，地址填写会混合IP、域名两种形式。IP的地址，便于规避内网DNS故障。域名形式，便于做个别节点更替或扩容。我们在设计产品架构时，为了安全性，开启了TLS证书认证，当节点变更时，证书的生成也同样要考虑到上面两种方案的影响，证书里需要包含固定IP，以及DNS域名范围的两种格式。etcd Cluster节点扩容节点扩容，官方手册上也有完整的方案，etcd的Client里实现了健康检测与故障迁移，能自动的迁移到节点IP列表中的其他可用IP。也能定时更新etcd Node List，对于etcd Cluster的集群节点变更来说，不存在问题。需要我们注意的是，TLS证书的兼容。分布式HIDS集群架构图集群核心组件高可用，所有Agent、Server都依赖集群，都可以无缝扩展，且不影响整个集群的稳定性。即使Server全部宕机，也不影响所有Agent的继续工作。在以后Server版本升级时，Agent不会中断，也不会带来雪崩式的影响。etcd集群可以做到单节点升级，一直到整个集群升级，各个组件全都解耦。编程语言选择考虑到公司服务器量大，业务复杂，需求环境多变，操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性，我们选择了Golang作为开发语言，它具备以下特点：可以静态编译，直接通过syscall来运行，不依赖libc，兼容性高，可以在所有Linux上执行，部署便捷。静态编译语言，能将简单的错误在编译前就发现。具备良好的GC机制，占用系统资源少，开发成本低。容器化的很多产品都是Golang编写，比如Kubernetes、Docker等。etcd项目也是Golang编写，类库、测试用例可以直接用，SDK支持快速。良好的CSP并发模型支持，高效的协程调度机制。产品架构大方向HIDS产品研发完成后，部署的服务都运行着各种业务的服务器，业务的重要性排在第一，我们产品的功能排在后面。为此，确定了几个产品的大方向：高可用，数据一致，可横向扩展。容灾性好，能应对机房级的网络故障。兼容性好，只维护一个版本的Agent。依赖低，不依赖任何动态链接库。侵入性低，不做Hook，不做系统类库更改。熔断降级可靠，宁可自己挂掉，也不影响业务 。产品实现篇幅限制，仅讨论框架设计、熔断限流、监控告警、自我恢复以及产品实现上的主进程与进程监控。框架设计如上图，在框架的设计上，封装常用类库，抽象化定义Interface，剥离etcd Client，全局化Logger，抽象化App的启动、退出方法。使得各模块（以下简称App）只需要实现自己的业务即可，可以方便快捷的进行逻辑编写，无需关心底层实现、配置来源、重试次数、熔断方案等等。沙箱隔离考虑到子进程不能无限的增长下去，那么必然有一个进程包含多个模块的功能，各App之间既能使用公用底层组件（Logger、etcd Client等），又能让彼此之间互不影响，这里进行了沙箱化处理，各个属性对象仅在各App的sandbox里生效。同样能实现了App进程的性能熔断，停止所有的业务逻辑功能，但又能具有基本的自我恢复功能。IConfig对各App的配置抽象化处理，实现IConfig的共有方法接口，用于对配置的函数调用，比如Check的检测方法，检测配置合法性，检测配置的最大值、最小值范围，规避使用人员配置不在合理范围内的情况，从而避免带来的风险。框架底层用Reflect来处理JSON配置，解析读取填写的配置项，跟Config对象对比，填充到对应Struct的属性上，允许JSON配置里只填写变化的配置，没填写的配置项，则使用Config对应Struct的默认配置。便于灵活处理配置信息。type IConfig interface { Check() error //检测配置合法性}func ConfigLoad(confByte []byte, config IConfig) (IConfig, error) {…//反射生成临时的IConfig var confTmp IConfig confTmp = reflect.New(reflect.ValueOf(config).Elem().Type()).Interface().(IConfig)… //反射 confTmp 的属性 confTmpReflect := reflect.TypeOf(confTmp).Elem() confTmpReflectV := reflect.ValueOf(confTmp).Elem() //反射config IConfig configReflect := reflect.TypeOf(config).Elem() configReflectV := reflect.ValueOf(config).Elem()… for i = 0; i < num; i++ { //遍历处理每个Field envStructTmp := configReflect.Field(i) //根据配置中的项，来覆盖默认值 if envStructTmp.Type == confStructTmp.Type { configReflectV.FieldByName(envStructTmp.Name).Set(confTmpReflectV.Field(i))Timer、Clock调度在业务数据产生时，很多地方需要记录时间，时间的获取也会产生很多系统调用。尤其是在每秒钟产生成千上万个事件，这些事件都需要调用获取时间接口，进行clock_gettime等系统调用，会大大增加系统CPU负载。 而很多事件产生时间的准确性要求不高，精确到秒，或者几百个毫秒即可，那么框架里实现了一个颗粒度符合需求的（比如100ms、200ms、或者1s等）间隔时间更新的时钟，即满足事件对时间的需求，又减少了系统调用。同样，在有些Ticker场景中，Ticker的间隔颗粒要求不高时，也可以合并成一个Ticker，减少对CPU时钟的调用。Catcher在多协程场景下，会用到很多协程来处理程序，对于个别协程的panic错误，上层线程要有一个良好的捕获机制，能将协程错误抛出去，并能恢复运行，不要让进程崩溃退出，提高程序的稳定性。抽象接口框架底层抽象化封装Sandbox的Init、Run、Shutdown接口，规范各App的对外接口，让App的初始化、运行、停止等操作都标准化。App的模块业务逻辑，不需要关注PID文件管理，不关注与集群通讯，不关心与父进程通讯等通用操作，只需要实现自己的业务逻辑即可。App与框架的统一控制，采用Context包以及Sync.Cond等条件锁作为同步控制条件，来同步App与框架的生命周期，同步多协程之间同步，并实现App的安全退出，保证数据不丢失。限流网络IO限制数据上报速度。队列存储数据任务列表。大于队列长度数据丢弃。丢弃数据总数计数。计数信息作为心跳状态数据上报到日志中心，用于数据对账。磁盘IO程序运行日志，对日志级别划分，参考 /usr/include/sys/syslog.h：LOG_EMERGLOG_ALERTLOG_CRITLOG_ERRLOG_WARNINGLOG_NOTICELOG_INFOLOG_DEBUG在代码编写时，根据需求选用级别。级别越低日志量越大，重要程度越低，越不需要发送至日志中心，写入本地磁盘。那么在异常情况排查时，方便参考。日志文件大小控制，分2个文件，每个文件不超过固定大小，比如20M、50M等。并且，对两个文件进行来回写，避免日志写满磁盘的情况。IRetry为了加强Agent的鲁棒性，不能因为某些RPC动作失败后导致整体功能不可用，一般会有重试功能。Agent跟etcd Cluster也是TCP长连接（HTTP2），当节点重启更换或网络卡顿等异常时，Agent会重连，那么重连的频率控制，不能是死循环般的重试。假设服务器内网交换机因内网流量较大产生抖动，触发了Agent重连机制，不断的重连又加重了交换机的负担，造成雪崩效应，这种设计必须要避免。 在每次重试后，需要做一定的回退机制，常见的指数级回退，比如如下设计，在规避雪崩场景下，又能保障Agent的鲁棒性，设定最大重试间隔，也避免了Agent失控的问题。//网络库重试Interfacetype INetRetry interface { //开始连接函数 Connect() error String() string //获取最大重试次数 GetMaxRetry() uint …}// 底层实现func (this *Context) Retry(netRetry INetRetry) error {… maxRetries = netRetry.GetMaxRetry() //最大重试次数 hashMod = netRetry.GetHashMod()for { if c.shutting { return errors.New(“c.shutting is true…”) } if maxRetries > 0 && retries >= maxRetries { c.logger.Debug(“Abandoning %s after %d retries.”, netRetry.String(), retries) return errors.New(“超过最大重试次数”) }… if e := netRetry.Connect(); e != nil { delay = 1 << retries if delay == 0 { delay = 1 } delay = delay * hashInterval… c.logger.Emerg(“Trying %s after %d seconds , retries:%d,error:%v”, netRetry.String(), delay, retries, e) time.Sleep(time.Second * time.Duration(delay)) }…}事件拆分百万台IDC规模的Agent部署，在任务执行、集群通讯或对宿主机产生资源影响时，务必要错峰进行，根据每台主机的唯一特征取模，拆分执行，避免造成雪崩效应。监控告警古时候，行军打仗时，提倡「兵马未动，粮草先行」，无疑是冷兵器时代决定胜负走向的重要因素。做产品也是，尤其是大型产品，要对自己运行状况有详细的掌控，做好监控告警，才能确保产品的成功。对于etcd集群的监控，组件本身提供了Metrics数据输出接口，官方推荐了Prometheus来采集数据，使用Grafana来做聚合计算、图标绘制，我们做了Alert的接口开发，对接了公司的告警系统，实现IM、短信、电话告警。Agent数量感知，依赖Watch数字，实时准确感知。如下图，来自产品刚开始灰度时的某一时刻截图，Active Streams（即etcd Watch的Key数量）即为对应Agent数量，每次灰度的产品数量。因为该操作，是Agent直接与集群通讯，并且每个Agent只Watch一个Key。且集群数据具备唯一性、一致性，远比心跳日志的处理要准确的多。etcd集群Members之间健康状况监控用于监控管理etcd集群的状况，包括Member节点之间数据同步，Leader选举次数，投票发起次数，各节点的内存申请状况，GC情况等，对集群的健康状况做全面掌控。程序运行状态监控告警全量监控Aagent的资源占用情况，统计每天使用最大CPU内存的主机Agent，确定问题的影响范围，及时做策略调整，避免影响到业务服务的运行。并在后续版本上逐步做调整优化。百万台服务器，日志告警量非常大，这个级别的告警信息的筛选、聚合是必不可少的。减少无用告警，让研发运维人员疲于奔命，也避免无用告警导致研发人员放松了警惕，前期忽略个例告警，先解决主要矛盾。告警信息分级，告警信息细分ID。根据告警级别过滤，根据告警ID聚合告警，来发现同类型错误。根据告警信息的所在机房、项目组、产品线等维度来聚合告警，来发现同类型错误。数据采集告警单机数据数据大小、总量的历史数据对比告警。按机房、项目组、产品线等维度的大小、总量等维度的历史数据对比告警。数据采集大小、总量的对账功能，判断经过一系列处理流程的日志是否丢失的监控告警。熔断针对单机Agent使用资源大小的阈值熔断，CPU使用率，连续N次触发大于等于5%，则进行保护性熔断，退出所有业务逻辑，以保护主机的业务程序优先。Master进程进入空闲状态，等待第二次时间Ticker到来，决定是否恢复运行。各个App基于业务层面的监控熔断策略。灰度管理在前面的配置管理中的etcd Key设计里，已经细分到每个主机（即每个Agent）一个Key。那么，服务端的管理，只要区分该主机所属机房、环境、群组、产品线即可，那么，我们的管理Agent的颗粒度可以精确到每个主机，也就是支持任意纬度的灰度发布管理与命令下发。数据上报通道组件名为 log_agent ，是公司内部统一日志上报组件，会部署在每一台VM、Docker上。主机上所有业务均可将日志发送至该组件。 log_agent会将日志上报到Kafka集群中，经过处理后，落入Hive集群中。（细节不在本篇讨论范围）主进程主进程实现跟etcd集群通信，管理整个Agent的配置下发与命令下发；管理各个子模块的启动与停止；管理各个子模块的CPU、内存占用情况，对资源超标进行进行熔断处理，让出资源，保证业务进程的运行。插件化管理其他模块，多进程模式，便于提高产品灵活性，可更简便的更新启动子模块，不会因为个别模块插件的功能、BUG导致整个Agent崩溃。进程监控方案选择我们在研发这产品时，做了很多关于linux进程创建监控的调研，不限于安全产品，大约有下面三种技术方案：方案Docker兼容性开发难度数据准确性系统侵入性cn_proc不支持Docker一般存在内核拿到的PID，在/proc/下丢失的情况无Audit不支持Docker一般同cn_proc弱，但依赖Auditd Hook定制高精确强对于公司的所有服务器来说，几十万台都是已经在运行的服务器，新上的任何产品，都尽量避免对服务器有影响，更何况是所有服务器都要部署的Agent。 意味着我们在选择系统侵入性来说，优先选择最小侵入性的方案。对于Netlink的方案原理，可以参考这张图（来自:kernel-proc-connector-and-containers）系统侵入性比较cn_proc跟Autid在「系统侵入性」和「数据准确性」来说，cn_proc方案更好，而且使用CPU、内存等资源情况，更可控。Hook的方案，对系统侵入性太高了，尤其是这种最底层做HOOK syscall的做法，万一测试不充分，在特定环境下，有一定的概率会出现Bug，而在百万IDC的规模下，这将成为大面积事件，可能会造成重大事故。兼容性上比较cn_proc不兼容Docker，这个可以在宿主机上部署来解决。Hook的方案，需要针对每种Linux的发行版做定制，维护成本较高，且不符合长远目标（收购外部公司时遇到各式各样操作系统问题）数据准确性比较在大量PID创建的场景，比如Docker的宿主机上，内核返回PID时，因为PID返回非常多非常快，很多进程启动后，立刻消失了，另外一个线程都还没去读取/proc/，进程都丢失了，场景常出现在Bash执行某些命令。最终，我们选择Linux Kernel Netlink接口的cn_proc指令作为我们进程监控方案，借助对Bash命令的收集，作为该方案的补充。当然，仍然存在丢数据的情况，但我们为了系统稳定性，产品侵入性低等业务需求，牺牲了一些安全性上的保障。 对于Docker的场景，采用宿主机运行，捕获数据，关联到Docker容器，上报到日志中心的做法来实现。遇到的问题内核Netlink发送数据卡住内核返回数据太快，用户态ParseNetlinkMessage解析读取太慢，导致用户态网络Buff占满，内核不再发送数据给用户态，进程空闲。对于这个问题，我们在用户态做了队列控制，确保解析时间的问题不会影响到内核发送数据。对于队列的长度，我们做了定值限制，生产速度大于消费速度的话，可以丢弃一些数据，来保证业务正常运行，并且来控制进程的内存增长问题。疑似“内存泄露”问题在一台Docker的宿主机上，运行了50个Docker实例，每个Docker都运行了复杂的业务场景，频繁的创建进程，在最初的产品实现上，启动时大约10M内存占用，一天后达到200M的情况。经过我们Debug分析发现，在ParseNetlinkMessage处理内核发出的消息时，PID频繁创建带来内存频繁申请，对象频繁实例化，占用大量内存。同时，在Golang GC时，扫描、清理动作带来大量CPU消耗。在代码中，发现对于linux/connector.h里的struct cb_msg、linux/cn_proc.h里的struct proc_event结构体频繁创建，带来内存申请等问题，以及Golang的GC特性，内存申请后，不会在GC时立刻归还操作系统，而是在后台任务里，逐渐的归还到操作系统，见：debug.FreeOSMemoryFreeOSMemory forces a garbage collection followed by an attempt to return as much memory to the operating system as possible. (Even if this is not called, the runtime gradually returns memory to the operating system in a background task.)但在这个业务场景里，大量频繁的创建PID，频繁的申请内存，创建对象，那么申请速度远远大于释放速度，自然内存就一直堆积。从文档中可以看出，FreeOSMemory的方法可以将内存归还给操作系统，但我们并没有采用这种方案，因为它治标不治本，没法解决内存频繁申请频繁创建的问题，也不能降低CPU使用率。为了解决这个问题，我们采用了sync.Pool的内置对象池方式，来复用回收对象，避免对象频繁创建，减少内存占用情况，在针对几个频繁创建的对象做对象池化后，同样的测试环境，内存稳定控制在15M左右。大量对象的复用，也减少了对象的数量，同样的，在Golang GC运行时，也减少了对象的扫描数量、回收数量，降低了CPU使用率。项目进展在产品的研发过程中，也遇到了一些问题，比如：etcd Client Lease Keepalive的Bug。Agent进程资源限制的Cgroup触发几次内核Bug。Docker宿主机上瞬时大量进程创建的性能问题。网络监控模块在处理Nginx反向代理时，动辄几十万TCP链接的网络数据获取压力。个别进程打开了10W以上的fd。方法一定比困难多，但方法不是拍脑袋想出来的，一定要深入探索问题的根本原因，找到系统性的修复方法，具备高可用、高性能、监控告警、熔断限流等功能后，对于出现的问题，能够提前发现，将故障影响最小化，提前做处理。在应对产品运营过程中遇到的各种问题时，逢山开路，遇水搭桥，都可以从容的应对。经过我们一年的努力，已经部署了除了个别特殊业务线之外的其他所有服务器，数量达几十万台，产品稳定运行。在数据完整性、准确性上，还有待提高，在精细化运营上，需要多做改进。本篇更多的是研发角度上软件架构上的设计，关于安全事件分析、数据建模、运营策略等方面的经验和技巧，未来将会由其他同学进行分享，敬请期待。总结我们在研发这款产品过程中，也看到了网上开源了几款同类产品，也了解了他们的设计思路，发现很多产品都是把主要方向放在了单个模块的实现上，而忽略了产品架构上的重要性。比如，有的产品使用了syscall hook这种侵入性高的方案来保障数据完整性，使得对系统侵入性非常高，Hook代码的稳定性，也严重影响了操作系统内核的稳定。同时，Hook代码也缺少了监控熔断的措施，在几十万服务器规模的场景下部署，潜在的风险可能让安全部门无法接受，甚至是致命的。这种设计，可能在服务器量级小时，对于出现的问题多花点时间也能逐个进行维护，但应对几十万甚至上百万台服务器时，对维护成本、稳定性、监控熔断等都是很大的技术挑战。同时，在研发上，也很难实现产品的快速迭代，而这种方式带来的影响，几乎都会导致内核宕机之类致命问题。这种事故，使用服务器的业务方很难进行接受，势必会影响产品的研发速度、推进速度；影响同事（SRE运维等）对产品的信心，进而对后续产品的推进带来很大的阻力。以上是笔者站在研发角度，从可用性、可靠性、可控性、监控熔断等角度做的架构设计与框架设计，分享的产品研发思路。笔者认为大规模的服务器安全防护产品，首先需要考虑的是架构的稳定性、监控告警的实时性、熔断限流的准确性等因素，其次再考虑安全数据的完整性、检测方案的可靠性、检测模型的精确性等因素。九层之台，起于累土。只有打好基础，才能运筹帷幄，决胜千里之外。参考资料https://en.wikipedia.org/wiki…https://www.consul.io/intro/v...https://golang.org/src/runtim...https://www.ibm.com/developer...https://www.kernel.org/doc/https://coreos.com/etcd/docs/…作者简介陈驰，美团点评技术专家，2017年加入美团，十年以上互联网产品研发经验，专注于分布式系统架构设计，目前主要从事安全防御产品研发工作。关于美团安全美团安全部的大多数核心开发人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。招聘信息美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们，欢迎简历请发至邮箱zhaoyan17@meituan.com具体职位信息可参考这里：https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw美团安全应急响应中心MTSRC主页：security.meituan.com ...