唯一小编 发布时间:2026-01-19
近日,由福建省互联网协会主办、福建省通信管理局指导、工信部相关研究部门支持的 “2025年福建省互联网企业综合实力研究评价” 结果正式揭晓。唯一网络子公司厦门市唯云网络科技有限公司、厦门市世纪网通网络服务有限公司(以下简称“唯云网络”和“世纪网通”)凭借卓越的综合实力,双双荣登 “2025年福建省互联网综合实力前50家企业” 榜单,用硬核实力斩获省级权威认可! 厦门市唯云网络科技有限公司(排名第25位) 深耕互联网服务领域,唯云网络以技术创新为核心驱动力,聚焦客户需求,在网络服务、数字化解决方案等业务板块持续突破。此次以第25名的优异成绩入选,彰显了其在行业内的稳健竞争力与良好口碑,未来将继续以更优质的服务赋能企业数字化转型。 厦门市世纪网通网络服务有限公司(排名第32位) 世纪网通凭借多年行业积淀,在技术研发、高效服务保障等方面形成独特优势,为众多客户提供稳定可靠的互联网服务支持。此次位列第32名,是对其专业能力与市场表现的有力佐证,后续将持续深耕细分领域,助力行业高质量发展。 两大子公司的双双上榜,不仅是各自实力的彰显,更印证了唯一网络战略布局的成效。未来,唯一网络及旗下子公司将以此为契机,不忘初心、砥砺前行,在技术创新、服务升级、产业赋能等方面持续发力,为福建省互联网产业的蓬勃发展贡献更多力量!
唯一小编 发布时间:2026-01-19
近日,厦门市数据管理局发布《关于算力服务机构入库名单的公示》,唯一网络子公司厦门市唯云网络科技有限公司(以下简称“唯云网络”)凭借领先的算力技术实力、成熟的服务能力与丰富的行业实践经验,成功入选厦门市第一批算力服务机构入库名单! 本次入库名单遴选严格遵循《厦门市进一步推动人工智能产业发展若干措施》等政策文件要求,经企业申报、专家评审、合规核查等多环节严谨筛选,最终确定首批入库机构。入选名单不仅是对企业技术实力的权威认可,更是对其在算力服务领域创新能力与行业价值的高度肯定。 唯云网络作为深耕算力服务领域的科技企业,多年来聚焦算力基础设施建设、行业场景化算力解决方案、算力增值服务等核心方向,为政企客户提供高效、安全、可扩展的算力支撑。此次成功入库,标志着公司在算力服务赛道的专业能力获得政府主管部门与行业专家的双重认可。 未来,唯云网络将以此为新起点,继续深耕算力服务领域,不断突破技术边界,深耕算力服务场景,用更坚实的技术实力、更优质的服务体验,为厦门数字经济高质量发展注入澎湃动能!
唯一小编 发布时间:2026-01-06
唯一小编 发布时间:2025-12-31
近日,中共东莞市委网络安全和信息化委员会办公室正式公布2026-2028年度东莞市网络安全技术支撑单位名单,广东唯一网络科技有限公司成功入选“网络安全应急支撑类”、“网络安全检查评估支撑类”双类别支撑单位,将在未来三年为东莞网络安全建设提供专业技术支撑服务。 此次遴选工作严格遵循“自主申报、材料初审、专家评审、社会公示”全流程规范,旨在选拔一批技术过硬、服务优质的企业,共同筑牢东莞市网络安全防线。作为深耕网络安全领域多年的企业,唯一网络能够从众多申报单位中脱颖而出,既是市委网信办对我们技术能力与服务水平的高度认可,更是对我们多年来坚守网络安全阵地、助力区域数字化安全发展的肯定。 网络安全是数字经济发展的基石,应急响应与安全检查评估则是网络安全防护体系的核心环节。为此,唯一网络组建了专业应急响应团队,建立7×24小时快速响应机制,面对病毒攻击、数据泄露、系统瘫痪等各类安全突发事件,能第一时间介入处置,为党政机关、企事业单位的网络安全 “保驾护航”。同时,依托成熟的安全评估体系和专业技术工具,可精准识别安全隐患,出具针对性整改方案,构建全周期安全防护屏障。 此次入选对唯一网络而言,既是荣誉更是沉甸甸的责任。未来三年,我们将严格遵守国家保密相关法律法规,恪守职业道德与行业规范,以专业化、规范化为准则精进技术服务,深度对接东莞网络安全建设需求,与各方携手构建安全可信的网络空间,为数字东莞建设及网络强国实践注入坚实动力,用专业与担当回应社会信任。
唯一小编 发布时间:2025-12-11
12月10日,以“AI赋能,智汇水乡”为主题的东莞水乡人工智能应用创新中心(以下简称“创新中心”)启动仪式圆满举行。在生态共建环节,唯一网络凭借其在算力领域的突出优势与行业影响力,被正式授予“东莞水乡人工智能生态联盟”首批合作伙伴称号。唯一网络副总裁刘坚先生作为企业代表上台接受授牌。 该创新中心是东莞水乡经济区落实“人工智能+”战略、推动产业智能化升级的关键载体,定位为“政产学研金介用”七位一体的协同创新平台。此次生态联盟的组建汇聚了人工智能技术链与产业链上的核心企业,标志着东莞水乡人工智能协同发展生态正式启航。 唯一网络作为国内知名的数字经济基础设施服务提供商,其在数据中心、云计算及智能算力领域的深厚积累与创新中心的“公共算力服务”板块高度契合。创新中心已整合接入超过200P的专用智能算力及3000P通用算力资源,唯一网络的加入将为该算力池的稳定、高效与持续扩容注入强劲动力,助力企业破解智能化转型中“找技术难、用技术贵”的痛点。 唯一网络副总裁刘坚先生在授牌后表示,非常荣幸能够成为东莞水乡人工智能生态联盟的创始成员。唯一网络将充分发挥自身在算力资源、技术服务和市场洞察上的优势,与创新中心及其他生态伙伴紧密协作,共同为东莞水乡乃至粤港澳大湾区的企业提供更优质、更高效的数字化与智能化转型支持,助力区域产业经济实现高质量发展。 此次获授首批生态合作伙伴,是唯一网络深耕数字经济建设、积极布局人工智能产业的重要里程碑。未来,唯一网络将以此为契机,与生态伙伴携手共进,为打造东莞乃至大湾区具有影响力的“人工智能+先进制造”应用示范区贡献力量。
唯一小编 发布时间:2025-12-10
近日,以 “智惠新时代,AI创未来” 为主题的湖南电信2025-2026年终端产业链大会圆满举办,大会聚焦终端生态与政企业务协同发展,期间同步开展了优秀政企战略渠道商颁奖环节,现场汇聚了终端产业链及政企业务领域的优质合作企业,共同见证荣誉时刻。 其中,唯一网络全资子公司——厦门市唯云网络科技有限公司凭借在政企渠道合作中的出色表现,成功斩获 “2025 年湖南电信优秀政企战略渠道商” 称号。唯一网络副总裁易志强先生代表公司登台,接过了这份沉甸甸的荣誉牌匾。 此次评选是湖南电信对合作企业的综合检阅,涵盖政企业务协同能力、服务品质与长期合作价值等维度,能获此殊荣,是湖南电信对唯云网络合作实力的高度认可。 作为湖南电信值得信赖的战略合作伙伴,唯云网络与湖南电信始终保持着稳定良好的合作关系:双方在政企数字化服务、通信资源整合等领域深度协同,以专业能力精准匹配政企客户需求,共同助力区域政企信息化业务的高质量发展。 这份荣誉是肯定,更是前行的动力。未来,唯云网络将继续与湖南电信深化战略协作,持续提升服务能力,为更多政企客户提供更优质的解决方案,共创更广阔的合作价值
唯一小编 发布时间:2025-11-27
为确保数据中心设备及网络持续安全稳定运行,全面提升运维团队应急响应与故障处置能力,唯一网络志享数据中心于 2025 年11月25日23:00至次日02:00,成功组织实施 “2025 年双路市电中断柴油发电机带载演练”。本次演练有效检验数据中心供电系统在极端情况下的可靠切换能力,进一步强化科学、高效、快速的应急机制,为客户业务连续性筑牢坚实保障。 一、参演人员 本次演练组织严密、协同高效,参与单位及人员包括:唯一网络志享数据中心全体员工、相关设备厂家技术支持团队、运营商代表、部分客户代表 二、演练前期准备 为确保演练顺利实施,2025年11月25日23:00,运维部组织召开演练预备会,明确演练流程、职责分工及安全事项,全面落实设备检查与预案复核工作,为夜间实战演练打下坚实基础。演练总指挥刘浩文宣布演练正式开始,并依据《人员分工表》部署具体任务,强调操作规范与安全保障。 三、场景实战检验 场景1:首路市电中断,母联自动投切。2025年11月26日00:00手动断开1#高压市电输入,高压母联柜在3秒内自动合闸,2#高压电源通过母联柜向1#高压末端设备供电。整个切换过程平滑迅速,所有设备供电恢复正常。 场景2:双路市电中断,柴发自启带载。 断开2#高压市电输入,柴油发电机组自动启动,通过发电机并机室出线柜对1#、2#高压末端设备供电。IT机房、精密空调等重要负载均由UPS/HVDC/EPS系统保障,运行正常。 现场确认:所有不间断电源设备运行正常,消防系统设备运行稳定,机房负载供电不间断,安全运行。 场景3:柴发持续带载,稳定运行50分钟。#1、#2高压末端负载由柴油发电机持续带载运行50分钟,验证了柴发系统在长时间供电中的稳定性和可靠性。 场景4:市电逐步恢复,系统平滑切换。演练依次恢复1#、2#高压市电输入,供电平稳过渡,末端负载设备运行正常。演练过程中,各岗位人员严密监控设备运行状态,通过对讲机实时汇报,展现了专业高效的团队协作。 四、演练成果与总结 2025年11月26日01:30,演练总结会议召开。本次历时近3小时的演练圆满完成,柴发带载过程正常,全程未对运营环境造成影响,末端负载运行正常。 “勤于操练,方可百战不殆”。我们深知,供电应急演练是运营工作中不可或缺的一环。通过此次实战演练,进一步夯实应对电网突发事件的能力,为客户打造更加安全、稳定的电力基础设施。 未来,唯一网络志享数据中心将持续完善客户通报机制,优化动环系统告警信息管理,为客户业务提供坚实可靠的数字底座。
唯一小编 发布时间:2025-11-24
2025年11月19日,唯一网络与亚马逊云科技在厦门集美软件园美仑酒店联合举办“智启未来 AI重塑:软件开发、客户管理与跨境电商新生态”技术沙龙。本次活动作为“创+会客厅”系列重要场次,聚焦Agentic AI、生成式AI在客户管理、跨境电商等热门赛道的技术演进与场景落地,通过系统化议题设置与实战案例,为现场近30名企业技术负责人、开发者呈现AI赋能产业变革的清晰路径。 一、Agentic AI:驱动软件行业迈向自主智能新阶段 亚马逊云科技解决方案架构师张鑫先生在《未来已来——Agentic AI驱动软件行业创新》开场分享中指出,AI正引领软件开发范式从“代码伴侣”向“自主智能体”演进,标志着行业进入自主智能新阶段。他详细阐述了技术从专用智能体、Agentic Coding到云端智能体的演进路径,并强调Multi-Agent协作模式通过角色分工显著提升了代码质量与开发效率。讲师进一步结合AI在全生命周期提效的最佳实践,展示了其如何从设计、开发、测试到运维全面重塑软件生产流程,最终通过Prompt-Driven开发等新范式,为软件行业带来前所未有的创新速度与生产力变革。 二、生成式AI赋能客户管理:从满意度提升到体验重构 亚马逊云科技解决方案架构师柯俊雄先生结合电商、金融等行业实践,深入解析了生成式AI如何重塑客户管理体验。他指出,这项技术正推动客户服务从传统的满意度提升迈向全方位的体验重构。 在具体落地层面,生成式AI展现出三大核心价值:通过智能会话分析实时捕捉客户情绪与意图,动态优化服务策略;基于用户历史行为生成个性化解决方案,有效提升满意度和复购率;构建从需求识别到系统调用的自动化运营闭环,实现全流程高效协同。 讲师特别分享了一个零售企业的成功案例:在接入生成式AI客服系统后,该企业客户问题的一次解决率显著提升至78%,同时人工转接率下降40%。这一实证充分展现了生成式AI在优化服务流程、降低运营成本方面的强大助力,标志着客户管理正进入智能化、个性化的新纪元。 三、跨境电商实战:生成式AI重塑用户体验与运营效率 亚马逊云科技解决方案架构师李锦鸿先生结合跨境电商高频刚需场景,系统化解析了生成式AI在用户体验优化与运营提效方面的创新实践。他指出,通过多语言智能客服技术,企业可基于大模型自动生成小语种客服方案,有效支撑全球市场拓展;在物流环节,AI能够实时识别订单异常并主动触达用户,显著降低客诉与客户流失率;在营销层面,结合商品特征与区域偏好批量生成高转化率素材,已成为提升广告效果的关键手段。 在技术架构方面,讲师特别强调依托Amazon Bedrock统一调度多模型的核心优势,该平台通过灵活调用最适合的模型处理不同任务,同时结合亚马逊自研芯片保障高并发场景下的稳定响应与成本可控,为跨境电商企业提供了高效、可靠的技术底座。这一整套系统化实践不仅重塑了用户全旅程体验,更实现了运营效率的质的飞跃。 企业AI落地正面临技术选型难、集成复杂度高、运维成本压力大等挑战。唯一网络基于与亚马逊云科技的深度合作,可为企业提供从架构设计、模型调优到代运维的全链路服务,尤其在跨境电商、智能制造、金融服务等领域已沉淀成熟解决方案。 当前生成式AI正深刻改变软件开发、客户管理与跨境电商的技术范式与商业逻辑,唯一网络将持续携手亚马逊云科技,通过“技术沙龙+行业深耕+生态联动”的形式,助力企业夯实AI技术底座,在智能化浪潮中赢得先机。
唯一小编 发布时间:2025-11-13
11月12日上午,由松山湖管委会统筹发展局副局长带队,松山湖、石龙、石排、企石、茶山、横沥、东坑、寮步、大朗、大岭山十镇街经济发展局、投资促进中心相关领导及同事组成的考察团,一行38人莅临唯一网络参观交流。唯一网络销售部东莞分公司总经理曾令涛全程负责接待,双方围绕 “人工智能赋能新型工业化典型应用案例和政策需求” 深入沟通,共话产业升级新机遇。 考察团一行首先走进唯一网络展示厅,在曾令涛总经理的讲解下,近距离了解唯一网络在数据中心、AI智算、云计算及云联网等方面的实践和前沿探索,深入了解唯一网络的发展历程和产业布局。 展厅参观后,双方转入会议室开展深度交流。曾令涛总经理通过专题PPT,系统讲解企业 “数据中心、AI智算、云计算、云联网” 四轮驱动业务体系,并将重点落在两大核心板块: 一方面,详细分享AI智算领域的实践成果 —— 包括为某互联网头部客户 “一周内完成132P高性能算力集群交付” 的应急响应案例,以及对接 “东莞2025-2027年人工智能算力补贴政策”的进展,明确唯一网络已成功入围市级算力服务平台供应商,可助力企业降本享政策; 另一方面,重点汇报公司作为 “东莞市中小企业数字化转型试点城市(国家级)数字化牵引单位” 的履职成效:累计为长安、企石、横沥等镇街33家企业提供数字化咨询诊断,协助近100家智能移动终端领域企业完成转型改造,覆盖生产执行数字化、供应链协同等关键场景。 交流中,考察团围绕产业实践与政策落地相关问题积极提问,曾令涛总经理结合项目经验与政策细则逐一细致解答,现场互动氛围热烈,政企双方就 “政策落地痛点”、“产业协同方向” 快速达成诸多共识。 交流尾声,考察团与唯一网络接待团队共同合影留念,本次参观交流圆满落幕。此次政企面对面沟通,不仅让十镇街主管部门深入了解唯一网络的技术能力与服务经验,更为后续精准对接政策资源、协同推进东莞新型工业化发展筑牢基础。未来,唯一网络将持续发挥自身优势,深化与各区镇的联动,为东莞产业升级注入更多数字动能
唯一小编 发布时间:2025-11-12
2025年11月,迎来我国第34个全国消防安全宣传月。为深入贯彻落实消防安全责任,强化数据中心全体人员的应急处置能力,切实保障人员生命安全与财产安全,公司组织开展了以消防疏散、灭火器材实操、人员抢救为核心内容的专项消防应急演练。本次演练立足实战需求,全面检验并提升了公司应急管理体系的实战效能。 数据中心作为关键信息基础设施的核心支撑平台,其消防安全直接关乎业务运行的连续性。鉴于火灾事故具有突发性强、破坏力大等特点,公司始终将消防安全置于战略高度,视为重中之重。为此,公司坚持开展常态化消防安全培训并组织实战化演练活动,以此不断健全应急预案体系,优化应急处置流程,全方位强化全体员工的安全意识。 01 演练情景 监控中心接到一楼A电池室烟感警报,值班人员立即行动,迅速调取该区域现场监控摄像头画面,发现火势尚处于初期阶段,仅见细微烟火,灭火组迅速进行分闸操作、切断相关电源,以防止火势因电力供应而扩大,并使用二氧化碳灭火器对火点进行初期火灾扑灭作业。 公司应急领导刘浩文迅速下达指令,即刻启动消防应急处理预案。应急疏散广播开启,疏散组迅速引导人员有序疏散,撤离至安全集合点。技术应急组第一时间赶赴1#、2# 低压配电房,专业且高效地关闭所有电梯电源,并在现场设置明显标识,严禁人员使用电梯逃生,避免因电梯故障引发二次危险。 在伤员营救场景中,一楼发现被困伤员一名,救护组迅速携带药箱、担架前往转移伤员到安全地带并及时开展心肺复苏抢救工作,同时拨打“120”请求医疗支援,由于火势超出预期迅速蔓延,消防控制室确认人员全部疏散后,立即启动七氟丙烷灭火系统模式模拟控制火势。 02 消防器材的使用指导 演练环节完成,为提高全体员工对灭火器材的使用能力,保安队长讲解并演示了灭火器、防毒面具、正压式空气呼吸器的使用方法,让全体员工对消防器材的使用方法及注意事项有了更全面的了解。 灭火器使用指导 防毒面具使用指导 正压式空气呼吸器使用指导 全员积极参与实操,提高自救能力。 演练圆满结束后,公司领导刘浩文对本次演练活动进行了全面且深入的总结。对参与人员在演练过程中展现出的熟练度以及各部门间默契的配合度给予了高度赞誉,特别指出,本次演练能够如此顺利地开展,离不开每一位参与者的辛勤付出与全力以赴,同时,对前期筹备工作的充分性表示了肯定。并对全体员工提出了明确要求:一旦遭遇消防问题,首要任务是确保人员安全,为此,大家必须熟悉各类防护用具的使用方法,掌握消防器材的操作要领,清楚逃生通道的具体位置。并着重强调:“消防安全乃数据中心之生命线,我们每一位员工都必须秉持高度的责任感,将此次演练中所积累的经验与成果,切实转化为日常工作中常态化的防控能力,共同筑起安全发展的坚实屏障。”
阿里云RDS分库分表扩容兑现平滑数据迁移 2020年,笔者负责的一个高德打车弹外订单系统进行了一次扩分库分表和数据库迁移。该订单系统全局部署在阿里云上,服务应用阿里云ECS部署,数据库采纳阿里云RDS,配置中心基于阿里云ACM自研,数据同步基于阿里云DTS自研以及自研分库分表组件、分布式ID组件等等。 此次进行扩分库分表的背景是,原4实例4库、各个库64张表一共256张表,部分单表已超千万量级,按目前每日单量量级,一年内单表会达到上亿条记载,单表数据量过大会带来数据库性能问题。 4实例(16C/64G/3TSSD),4库(各个实例一个库),每库64张表,共256张表。 经过RDS后台一键诊断功能,来计算表空间应用情形(这里拿测试情境数据库举例)。 数据库的瓶颈主要表现在:磁盘、CPU、内存、互联网、联结数,而联结数主要是受CPU和内存作用。CPU和内存可以经过动态升配来提高,可是SSD磁盘容量最大支持到6T(32C以下最大3T、32C及以上最大6T)。 可是现阶段兼顾成本,可先将实例扩容一倍,采纳8个实例(16C/64G/3TSSD),各个实例建4个库(database)、各个库128张表(这里实质上是一个成本取舍的流程,理论上应该采取”多库少表”的准则,单库128张表其实太多了,单库建议32或64张表为宜)。 接下来如果实例压力提高可进行实例配置改进(16C/128G、32C/128G、32C/256G等);将来如出现单实例升配无法解决,在考虑扩容实例,只需求将database迁移至新实例,迁移成本较小。 按单表最多1000w条数据评估,4096张表可支持日5000w单3年(10.1压测标准)、日2000w单5年的架构。(因业务表比较多,此处忽略掉单条数据大小的计算流程) 32个库,各个库128张表。将来可最大扩容到32个实例,无需rehash,只需求迁移数据。 阿里云RDS规格和价钱一览 因扩分库分表涉及到rehash流程(256表变4096表),而阿里云DTS只支持同构库数据迁移,所以我们基于DTS的binlog转kafka实力自研了数据同步中间件。 整体数据迁移工作包含:前期预备、数据同步环节(历史数据全量同步、增量数据实时同步、rehash)、数据校验环节(全量校验、实时校验、校验规章配置)、数据修复工具等。 在进行数据同步前,需求先整理一切表的惟一业务ID,只有确定了惟一业务ID才学兑现数据的同步操作。 需求重视的是: 一旦表中没有惟一索引,就会在数据同步流程中造成数据重复的危险,所以我们先将没有惟一索引的表依据业务场景增加惟一索引(有也许是联合惟一索引)。 在这里顺便提一下,阿里云DTS做同构数据迁移,应用的是数据库自增ID做为惟一ID应用的,这种情形如果做双向同步,会造成数据覆盖的问题。解决案例也有,之前我们的做法是,新旧实物采纳自增ID单双号解决,担保新旧实例的自增ID不会出现冲突就行。由于这次我们应用的自研双向同步组件,这个难题这里不细聊。 分表规章不同决定着rehash和数据校验的不同。需逐个表整理是用户ID纬度分表还是非用户ID纬度分表、是否只分库不分表、是否不分库不分表等等。 数据同步全局案例见下图,数据同步基于binlog,独立的中间服务做同步,对业务代码无侵入。 后续对每一个环节进行介绍。 单独一个服务,应用游标的方法从旧库分批select数据,通过rehash后批量插入(batchinsert)到新库,此处需求配置jdbc联结串参数rewriteBatchedStatements=true才学使批处理操作生效。 另外特殊需求重视的是,历史数据也会存在不断的更新,如果先开启历史数据全量同步,则刚同步达成的数据有也许不是最新的。所以这里的做法是,先开启增量数据单向同步(从旧库到新库),此时只是开启积压kafka消息并不会真正消费;然后在开始历史数据全量同步,当历史全量数据同步达成后,在开启消费kafka消息进行增量数据同步(提升全量同步效率变少积压也是核心的一环),这样来担保迁移数据流程中的数据一致。 增量数据同步考虑到灰度切流稳定性、容灾和可回滚实力,采纳实时双向同步案例,切流流程中一旦新库出现稳定性问题或者新库出现数据一致问题,可迅速回滚切回旧库,担保数据库的稳定和数据稳妥。 增量数据实时同步采纳基于阿里云DTS的数据订阅自研数据同步组件data-sync兑现,主要案例是DTS数据订阅实力会自动将被订阅的数据库binlog转为kafka,data-sync组件订阅kafka消息、将消息进行过滤、合并、分组、rehash、拆表、批量insert/update,最后再上交offset等一系列操作,最终达成数据同步工作。 整体流程中有几个问题需求重视: 问题1:怎样预防因异步消息无顺序而致使的数据一致问题? 第一kafka异步消息是存在顺序问题的,可是要知道的是binlog是顺序的,所以dts在对具体进行kafka消息投递时也是顺序的,此处要做的就是一个库担保只有一个顾客就能保障数据的顺序问题、不会出现数据状态覆盖,从而解决数据一致问题。 问题2:是否会有丢消息问题,假如顾客服务重启等情形下? 这里没有采纳自动上交offset,而是每次消费数据最终入库达成后,将offset异步存到一个mysql表中,如果顾客服务重启宕机等,重启后从mysql拿到最新的offset开始消费。这样惟一的一个问题也许会出现瞬间部分消息重复消费,可是由于上面介绍的binlog是顺序的,所以能担保数据的最终一致。 问题3:update转insert会不会丢字段? binlog是全字段发送,不会存在丢字段情形。 问题4:循环消息问题。 后面进行单独介绍。 前文有提到,由于是256表变4096表,所以数据每一条都需求通过一次rehash重新做分库分表的计算。 要说rehash,就必须先介绍下目前订单数据的分库分表策略,订单ID中冗余了用户ID的后四位,经过用户ID后四位做hash计算确定库号和表号。 数据同步流程中,从旧库到新库,需求拿到订单ID中的用户ID后四位模4096,确定数据在新库中的库表位置;从新库到旧库,则需求用用户ID后四位模256,确定数据在旧库中的库表位置。 想象一下,业务写一条数据到旧实例的一张表,于是诞生了一条binlog;data-sync中间件接到binlog后,将该记载写入到新实例,于是在新实例也诞生了一条binlog;此时data-sync中间件又接到了该binlog……不断循环,消息愈来愈多,数据顺序也被打乱。 怎样解决该问题呢?我们采纳数据染色案例,只要能够标识写入到数据库中的数据使data-sync中间件写入而非业务写入,当下次接收到该binlog数据的时候就不必进行再次消息流转。 所以data-sync中间件需求,各个数据库实例创建一个事务表,该事务表tb_transaction只有id、tablename、status、create_time、update_time几个字段,status默认为0。 再回到上面的问题,业务写一条数据到旧实例的一张表,于是诞生了一条binlog;data-sync中间件接到binlog后,如下操作: 此时data-sync中间件将上面这些语句打包全体上交到新实例,新实例更新数据后也会生产对应上面语句的binlog;当data-sync中间件再次接收到binlog时,只要推断碰到tb_transaction表status=1的数据开始,后面的数据都直接舍弃不要,直到碰到status=0时,再陆续接收数据,以此来担保data-sync中间件只会流转业务诞生的消息。 数据校验模块由数据校验服务data-check模块来兑现,主要是基于数据库层面的数据对照,逐条核对每一个数据字段是否一致,不一致的话会通过配置的校验规章来进行重试或者报警。 通过数据校验,一旦发觉数据不一致,则需求对数据进行修复操作。 数据修复有两种案例,一种是适用于大范围的数据不一致,采纳重置kafkaoffset的方法,重新消费数据消息,将有问题的数据进行覆盖。 全局灰度案例:SP+用户纬度来兑现,SP纬度:凭仗灰度情境切量来做,用户纬度:依靠用户ID后四位百分比切流。 灰度切量的流程肯定要配合停写(秒级),为什么要停写,由于数据同步存在肯定拖延(正常毫秒级),而一切业务操作肯定要保障都在一个实例上,否则在旧库中业务刚刚调整了一条数据,此时切换到新库如果数据还没有同步过来就是旧数据会有数据一致问题。所以流程应该是: 虽然在切流之前,在测试情境进过了大量的测试,可是测试情境毕竟和生产情境不相同,生产情境数据库一旦出问题就也许是灭顶之灾,虽然上面介绍了数据校验和数据修复步骤,可是把问题拦截在发生之前是做服务稳定性最重大的工作。 因此我们提出了ABC验证的概念,灰度情境ABC验证预备: 详细灰度案例和数据源切换步骤: 整体数据迁移流程还是比较复杂的,时光也不是非常充裕(流程中还穿插着十一全链路压测改变),在有限的时光内集大家之力重复探讨发掘也许存在的问题,然后论证解决案例,不放过任何一个也许出现问题的环节,还是那句话,把问题拦截在发生之前是做服务稳定性最重大的工作。 流程中的细节还是非常多的,从数据迁移的预备工作到数据同步测试,从灰度步骤确定到正式生产切换,尤其是融合业务和数据的特色,有非常多需求考虑的细节,文中没有一一列出。 最终通过近两个月的紧张工作,无业务代码侵入、零事故、平稳地达成了扩分库分表和数据迁移的工作。
唯一小编 2021-03-01 阿里云服务器
腾讯云Terraform初始化 改进terraform到v0.13后,初始化terraform也许会出现以下问题 因素是terraform自v0.13后就交给provider自己维持了。解决案例: 1.应用命令查看自己版本 示例得到 +provider.tencentcloudv1.53.0 2.粘贴以下代码至terraform配置中,version采纳自己的tencentcloudterraform版本
唯一小编 2021-03-01 腾讯云服务器
阿里云无服务器高弹性的架构 在网络相关的业务中,高弹性是往往被提及的一个架构设计目的,前两个我就碰到一个用户需求我们帮助设计一个高弹性的架构以承载他们周期性暴增的业务压力,用户90%以上的业务压力都集合在业务高峰期,因此在设计这个架构之初,我和用户就在纠结,到底是采纳更了解的“堆”服务器的想法呢,还是采取更具弹性的容器化的案例呢?其实作为一个技术人员,在问这个难题的时候就已经有确定的答案了,最终我们设计出了这样的一个架构: 容器平台选择阿里云的ACK(阿里云容器服务Kubernetes版)。其中ACK分成专有版和托管版,区分是专有版的管控节点需求用户自行预备,而托管版应用阿里云的资源进行资源管控,在托管版中又分成标准版和Pro版,其中Pro版有确定的SLA保障,生产系统建议选择Pro版。同时为了保障worker节点的内容安全,建议为充当worker节点的ECS配置云安全中心服务进行主机安全防护。 除了ACK,阿里云还提供无服务器架构的ASK,区分是ACK有ECS服务器充当worker节点,创建POD所需的资源经过ECS进行安排,而ASK没有worker节点,ASK直接在阿里云的分享资源池中经过ECI(弹性容器节点)来安排资源创建POD。 在这个项目中为了担保永远有肯定量的稳定资源供给,我们决定应用ACK再融合阿里云的ECI来兑现资源的弹性供给。ECI资源的申请和释放可经过ACK的ack-virtual-node插件出自动达成,动态增加的POD将自动运行在ECI之上。 考虑到业务高峰期和平常存在庞大的应用量落差,选择应用按流量的方法购入手互联网带宽资源,并经过购入手分享流量包将一切的互联网流量进行集合抵扣。这个项目所用到的互联网流量主要有如下三个: 鉴于ECI节点上服务的启动需求肯定的时光,而业务流量也许瞬间到达峰值,因此经过MQ来缓冲瞬时的业务压力,为运行在ECI弹性资源上的服务争取启动时光。 阿里云MQ服务依据访问协议的不同分成RocketMQ、AMQP、Kafka三个系列,对于海量的业务交易场景建议选择通过双十一检验的RocketMQ系列,在RocketMQ系列中又分成一般版和公司铂金版两个版本,公司铂金版采纳独享硬件资源,能够更充分的保障峰值吞吐实力,对于瞬时业务峰值高的业务,建议尽也许选择铂金版。 数据库采纳云原生数据库PolarDB,PolarDB可以从2个节点扩容到16个节点,单节点可改进至88核710G规格,集群采纳分布式分享存储架构,单个集群可存储100TB的数据,有赖于其采纳分布式分享存储的架构,PolarDB集群增加节点时无需进行大量的数据拷贝,因此可以在分钟级达成集群的横向扩容。 我觉得这个架构对于大部分“腰部”级其他网络行业用户都是适用的,因此共享出来,盼望对大家有所协助。
唯一小编 2021-03-01 阿里云服务器
云专线和普通专线区别 云专线和普通专线区别,首先我们说一下云专线在定义和应用方 面的区别。 普通物理专线,是端口带宽资源被用户独占的物理专线,此种类型的物理专线由用户单独使用该物理线路,专线用户可以创建多个虚拟接口。 云专线(Direct Connect)用于搭建用户本地数据中心与云上VPC之间高速、低时延、稳定安全的专属连接通道。 传统专线主要应用于用户的局域网互联或快速浏览互联网。用户可以根据需要选择64Kbps- 2Mbps不等的速率。通过互联专线实现数据、语音、图像等业余的安全传输:实现各公司、部门间的资源交换和共享;通过拥有固定、独享的IP地址,视需要建立自己的Mail-Server. Web- Server等服务器,并可通过Internet组建公司内部的VNP业务。 云专线是连接客户局域网与行业云的专线网络,全程独立通道,能够不经互联网连接云主机,同时能保证高网速,对于银行、金融机构等高保密性要求的客户具有重要意义。 下面,我们在分别从开通时间、费用、弹性伸缩、稳定性等维度对他们之间的区别进行说明: 对比一下可以发现 , VPN是开通便捷,费用上比云专线要低很多,但是在公网的质量保障上不如专线,时延高,安全性不如云专线强。相对来说云专线低时延、服务质量稳定,但是在费用上就较高一些。而且在开通时间上,因为受限于物理专线的部署、运营商的线路资源的情况,所以部署时间要比VPN长。在这个情况下,一个量级, VPN如果双方都有internet资源的话,基本上是即开即用,双方配置好,协商起来就可以通信。但是云专线一般是将数据中心和公有云VPC对接,这个时候受限于物理链路,要运营商去核查资源,要去做物理线路的对接。这些正常情况下,就运营商的承诺。有诺的时间一般都是至少需要20个工作日。云专线线上的配置开通,现在一般也是天级,在拿到这种线路配置信息,且物理专线对接完以后,在一天内就可以完成这个线路配置打通的。 唯一网络是中国市场专业的云托管服务商( Cloud MSP ),在数据中心和云计算领域有近十年的专业交付和管理经验,目前正服务于2000多家企业级客户并与全球多家超大规模公有云服务商建立了战略合作关系。在云计算驱动产业变革的今天,安畅以客户需求为驱动,积极投资于核心技术研发和团队组织的云原生技能,致力于成为IT新生态和产业互联网的新-代连接器。 为客户提供”云+大数据+AI”的咨询、集成和管理服务,以及数字化解决方案,帮助客户利用新技术进行业务创新,实现数字化变革。
唯一小编 2021-02-19 专线