首页 文章 精选 留言 我的

精选列表

搜索[API选型]，共10000篇文章
优秀的个人博客,低调大师

优测领衔云测平台推荐与选型指南

移动应用质量保障正在经历从"自建真机实验室"向"云端按需调用"的结构性迁移。据《2025年中国云测试行业发展报告》显示，2025年国内移动端自动化测试市场规模预计达到180亿元，年复合增长率（2022—2025）达12.5%，其中AI驱动的自动化测试占比超40%，成为市场增长的核心动力。另一组数据同样印证了这一趋势：全球移动测试市场2024年约93.67亿美元，预计2031年增长至216.9亿美元，年复合增长率13.0%，自动化测试为最大细分品类，约占78%市场份额。设备碎片化进一步加剧了这一需求——2025年国内在活跃移动设备超2000款型号，Android版本分化率达34%，鸿蒙NEXT市占率突破18%，中小团队难以独立构建完整真机矩阵。
2026-08-14
优秀的个人博客,低调大师

云原生架构下的微服务选型和演进

作者：彦林 本文整理自阿里云智能高级技术专家彦林的线上直播分享《云原生微服务最佳实践》。视频回放地址：https://yqh.aliyun.com/live/detail/28454 随着云原生的演进，微服务作为主流应用架构被广泛使用，其落地的难题逐步从如何建好延伸到如何用好。今天跟各位小伙伴分享一下我在微服务领域 10 余年的实践经验，如何以更高效的姿势把微服务这件事做扎实。 阿里微服务发展历程 微服务 1.0 （1w 实例/微服务拆分/同城容灾） 2008 年随着阿里业务规模不断增大，单体胖应用+硬负载的架构逐渐暴露性能瓶颈；随着研发人员逐步增多，协调效率也逐步下降，不能满足日益复杂的业务挑战，因此急需技术升级解决这些问题。 在当时 SOA 架构非常流行，也就成为我们技术演进的主要方向，当时有两种解决方案，一个是 Server Based 的解决方案，这种模式侵入小、方便集中管控，但是这种中心化方案会带来成本高、稳定性风险高、扩展性差；一个是 Client Based 的解决方案，这种模式去中心化，扩展性强，成本低，但是会带来一定侵入性，比较难以管理；当然很多人会问为什么不直接用 DNS 呢？主要是 DNS 不能满足 IDC 内部服务发现实时性，服务列表更新不能及时通知下有业务会导致业务流量损失。 在评估两种方案利弊之后，我们在网关这种需要集中管理安全和简单路由场景采用了 Server Based 的方案，基于 Nginx 演进出了阿里 Tengine 网关技术体系，从入口处解决安全、高可用、简单路由能力；在 IDC 内部采用了 Client Base 模式，孵化出 HSF/Dubbo+Nacos 技术体系，支撑了业务微服务拆分。 随着第一代微服务架构落地，由于引入注册中心带来了稳定性风险，注册中心挂会导致调用链路全部中断；业务集中发布的时候注册中心压力会比较大。 针对可用性问题我们提供了推空保护能力，即使注册中心挂也不会影响业务正常运行；为了提供更好性能我们提供了全异步架构；为了支持同城容灾我们提供了 AP 一致性协议，具体协议可以参考《Nacos 架构与原理》电子书。 随着阿里微服务 1.0 架构落地，帮助业务完成微服务拆分，解决了扩展性和协同效率问题，同时支撑了阿里同城容灾能力。对于正在做微服务的小伙伴可能问阿里如何做微服务架构演进的： 前后端分离是第一步，因为前端变化多，变化快，后端相对变化小，演进慢，因此需要解耦发展，让前端更快的适应市场变化，以便在竞争中保持先机； 后端无状态改造是第二步，把内存状态外置到 Redis，把持久化状态外置到 Mysql，这样业务就可以随意进行切分； 第三步是模块化拆分，这块是最考验架构师的，因为拆分一个是按照业务属性拆分，一个是按照应用复杂度进行拆分，这个是一个相对动态过程，建议拆分模块后 2-3 人负责一个模块，拆到太细会有比较高的运维成本，拆的太粗又会带来研发协同问题，阿里内部也经历过合久必分，分久必合的几波震荡，最终走到相对稳态。这里值得一提就是 HSF/Dubbo 的一个优势，因为早期采用 SOA 架构思想设计，一个接口就是一个服务，这样其实非常方便服务的拆分和合并，当然同时带来一个问题是对注册中心性能压力比较大，这是一个架构选择和平衡问题。 微服务 2.0（10w 实例/业务中台/异地多活） 微服务 1.0 架构帮助阿里极大缓解性能和效率问题，但是由于阿里双十一的成功，技术上面临一个洪峰的技术挑战，我们必须在用户体验、资源成本、高可用之间做一个平衡。这个阶段我们最大的挑战是扩展性和稳定性，扩展性是要支撑业务 10w+实例扩容，但是单地资源有限，双十一商家投入的资金越来越大，导致我们双十一当天也不能出严重问题，不然损失非常大，因此对业务稳定性提出非常高的要求。 因此阿里演进到微服务 2.0 支撑了异地多活的高可用体系，让阿里业务可以按照 IDC 级别水平扩展，新的机房，新的技术体系都可以在单元中进行验证，也加速了阿里技术体系演进速度。 在此期间 Nacos Server 间水平通知压力巨大，业务发布窗口容易把网卡打满，频繁推送会消耗业务大量内存和 CPU，进而影响业务的稳定性。 针对上述问题，我们在 Nacos Server 间做了聚合推送，将一定时间窗的变更合并聚合推送，推送过程中做了压缩推送，从而解决了上述问题。 在微服务解决扩展性和高可用的同时，业务系统变多，重复建设，业务孤岛也越来越多，协同效率也越来越低，因此阿里业务在这个时候推出了业务中台能力，将扁平的微服务抽象分层，将基础服务抽象为中台服务解决上述问题，业务分层后支撑了阿里业务高速增长，也加速了技术架构统一。 微服务 3.0（100w 实例/业务域拆分/云原生） 微服务 2.0 架构支撑了阿里双十一的技术奇迹，阿里也陆续开启业务扩张，构建更完整的互联网版图。在这个阶段阿里收购了比较多的公司，技术体系不统一如何形成合力；从线上走到线下后，线下系统对系统稳定性要求更高；云计算发展，如何利用好云的弹性做双十一，这个阶段我们也推出了微服务的云产品，期望通过云产品支撑阿里双十一。 业务域切分比较容易，切完之后如何更好的互联互通是一个关键，因此我们内部推出了 Nacos-sync 和云原生网关两个产品。Nacos-sync 适合业务流量超大，协议一致场景。云原生网关适合网络不通，协议不同，跨 Region 等场景。 即使从顶层做了业务域拆分，但是最大的电商集群往百万实例演进过程中对注册中心的压力越来越大，我们把聚合窗口时间不断拉长，推送慢了会导致业务发布时间变长，推送快了会对业务消耗较大，因此陷入了两难境地。 这个阶段我们进行问题的分解，首先根据服务列表大小做了一个切分，服务列表多的可以推送慢一些问题也不大，服务列表小的需要及时推送，因此我们优化了聚合推送逻辑，根据服务列表大小做了分级推送。还有一个优化思路是变更只有几个列表变化，因此我们提供了增量推送能力，大幅降低服务变更推送数据量。 通过微服务 3.0 架构演进很好的解决了跨域互通和平滑上云的问题，新业务可以先上云，或者部分业务上云，通过网关做云上云下互通等问题，同时支撑了百万实例微服务架构演进。 期望通过我分享阿里微服务发展历程给大家做微服务架构演进提供一些思路和启发。 云原生微服务趋势 随着云原生技术演进，容器以不可变基础设施为理念，解决运维标准和资源利用率问题；微服务以可变运行时为理念，解决研发效率问题，提升系统整体扩展性和高可用。经常有人问我，为什么有了容器的服务发现机制，还需要微服务的注册中心呢？从架构上首先是分层的，小的时候确实也看不到明显区别，大一些就会发现问题，如阿里中心最大微服务集群，底层是多个 Kubernetes 集群，防止一个 Kubernetes 出问题影响全局，底层 Kubernetes 也可以水平扩展，如果依赖了 Kubernetes 的服务发现机制，跨 Kubernetes 服务发现就成了第一个问题。当然底层是一个 Kubernetes 上面也可以是多个微服务环境，微服务可以按照业务域切分。两层可以做解耦，自由环境组合。还有就是阿里微服务体系积累了推空保护、服务治理完整体系，而 Kubernetes 的 CoreDNS 将服务发现强制拉到业务调用链路，每次调用都会做域名解析，因此 CoreDNS 挂的时候业务全部中断。 对于阿里整体正在从百万实例往千万实例的规模演进，这部分也是阿里微服务 4.0 的内容，这部分给大部分公司的借鉴意义有限，因此不做展开。 微服务最佳实践 阿里微服务体系经过 10 余年的发展，目前已经通过开源被广泛使用，通过阿里云支撑了成千上万家企业做数字化升级。借此机会把我们的最佳实践总结分享给大家，期望都对大家用好微服务有所帮助。 阿里微服务体系简介 通过 MSE + ACK 能够完成第一步云原生技术升级，释放云弹性红利，释放研发效率红利，可以通过可观测和高可用进一步用好微服务体系。 微服务最佳实践 通过注册&配置中心完成微服务拆分；通过网关统一入口，从入口处解决安全和高可用问题；最后通过服务治理提升用户微服务的问题。 网关最佳实践 云原生网关作为下一代网关，提供高集成、高可用、高性能、安全的一站式网关解决方案。 • 统一接入：将流量网关、 微服务网关、 WAF 三合一大幅降低资源和运维成本，需要强调的是云原生网关集成 WAF 的方案有非常好的性能优势，WAF 做为控制面下发防护规则到云原生网关，流量直接在云原生网关清洗完毕直接路由到后端机器，RT 短，运维成本低。 • 统一入口安全防线：自动更新证书防过期，支持 JWT/OAuth2/OIDC/IDaaS 认证机制，支持黑白名单机制。 • 统一东西南北流量：统一解决跨域互通问题，包括跨网络域，跨业务域，跨地域，跨安全域等。 • 统一服务发现机制：支持 Nacos/Kubernetes/DNS/ 固定 IP 多种服务发现方式。 • 统一观测平台：从入口做好 tracing 埋点全链路诊断，丰富业务大盘和告警模板大幅降低网关运维成本。 • 统一服务治理：从入口做限流、降级、熔断等高可用能力，提供全链路灰度方案控制变更风险。统一性能优化：采用硬件加速性能提升 80%，Ingress 场景比 Nginx 性能高 90%，参数调优+模块优化提升 40%。 云原生网关支持 WASM 扩展网关自定义功能，并且通过插件市场提供丰富的插件能力。 服务治理最佳实践 提供零业务侵入，开发，测试，运维全覆盖服务治理能力，提升系统高可用。如发布阶段即使注册中心是毫秒级推送也会有延迟，这个期间就会导致流量损失，因此我们提供了无损上下线能力解决这个痛点。本月我们将服务治理能力通过 OpenSergo 开源，欢迎各位小伙伴参与共建！ 日常环境隔离最佳实践 共享一套环境联调开发相互影响，所有环境都独立联调机器成本太高，这个是一个矛盾，我们通过全链路打标能力将流量隔离，让大家可以在一套环境隔离多个逻辑联调环境，巧妙的解决这个问题。 配置管理最佳实践 随着应用规模变大，到每个机器去修改配置运维成本太高，因此需要配置中心统一维护应用配置，将静态业务动态化，动态修改业务运行时行为，提升应用运行时灵活性。 服务网格最佳实践 对于多语言开发有诉求和对服务网关感兴趣的小伙伴可以通过 MSE+ASM 快速构建服务网格解决方案，完成服务互通，快速体验新的技术。 微服务高可用最佳实践 随着业务复杂度变高，业务峰值不可测，面对失败的设计和微服务高可用工具使用就非常重要，可以通过 Sentinel 完成限流、降级、熔断的保护，可以通过 PTS 完成压测，可以通过混沌工程完成破坏性测试，从体整体提升系统高可用。 注册中心平滑迁移实践 目前大规模场景推荐双注册，如 1w 实例以上，这样发布周期长，稳定性更高一些。如果不到 1w 实例可以通过 Nacos-sync 同步完成注册中心平滑前一，这样通用型强一些。 网关平衡迁移实践 由于前面云原生网关三合一和性能优势，大家可以通过入口 DNS 灰度切换到云原生网关。 微服务标杆客户 用户上云中有两类典型客户，一类是传统的单体胖应用客户，一类是已经采用了微服务需要用好微服务的用户，我们通过两个标杆客户分享一下。 斯凯奇微服务＋业务中台实践 斯凯奇 2021 年找到我们做数字化升级时间非常紧急，需要双十一前 3 个月左右要完成数字化升级，采用 MSE 微服务+中台解决方案，斯凯奇借助云原生网关完成了东西南北流量的统一控制，借助南北向云原生网关完成安全认证和入口限流，从入口做好流量防护；借助东西向网关完成了多个业务域的互通，新老系统的互通，1 个月左右完成了整个系统的搭建，1 个月左右完成了整个系统压测和高可用验证，并且最终大促业务非常成功，助力斯凯奇双十一 12 亿营收规模。 来电微服务全链路灰度最佳实践 来电的技术挑战 来电科技的业务场景丰富且系统众多，在技术架构上已完成容器化以及微服务化改造，微服务框架使用的是 Spring Cloud 与 Dubbo。随着近年来的高速发展，充电宝设备节点以及业务量都在快速增加，系统的稳定性面临几点挑战: 1.在系统服务的发布过程中如何避免业务流量的损失； 2.系统缺少简单有效的灰度能力，每次系统发布都存在一定的稳定性风险。MSE 微服务治理提供了开箱即用且无侵入的线上发布稳定性解决方案以及全链路灰度解决方案，帮助来电科技消除发布风险、提升线上稳定性。 来电全链路灰度最佳实践 1.来电科技选用 MSE 微服务治理专业版来实现无侵入微服务治理能力，无缝支持市面上近 5 年所有的 Spring Cloud 和 Dubbo 的版本，不用改一行代码，不需要改变业务的现有架构就可以使用，没有绑定。 2.MSE 微服务治理专业版提供了全链路灰度解决方案帮助来电科技快速落地可灰度、可观测、可回滚的安全生产三板斧能力，满足业务高速发展情况下快速迭代和小心验证的诉求； 3.MSE 微服务治理的无损上下线能力，对系统服务的全流程进行防护，通过服务预热、无损下线、与 Kubernetes 微服务生命周期对齐、延迟发布等一系列能力，保证在服务冷启动或销毁过程中，业务连续无损。 4.MSE 微服务治理的离群实例摘除能力，可以做到让服务消费者自动检测其所调用提供者实例的可用性并进行实时的权重动态调整，以保证服务调用的成功率，从而提升业务稳定性和服务质量。 阿里云微服务生态与规划 阿里开源微服务会贴着服务治理帮助开发者用户微服务，云产品做好产品集成提升大家的使用体验。 ACK+MSE = 云原生架构升级解决方案 ASM+MSE = 服务网格解决方案 AHAS + MSE = 微服务高可用解决方案 ARMS + MSE = 微服务可观测解决方案 EDAS + MSE = APaaS解决方案 SAE + MSE = 微服务 Serverless 解决方案 WAF + 云盾 + IDaaS + MSE = 微服务安全解决方案 运营活动 限时折扣（4.21-4.30） 微服务全家桶，省、省、省～ 下期预告 - Kubernetes Ingress 最佳实践 随着 Kubernetes 普及，Ingress 成为云原生架构的流量入口，云原生网关作为 Ingress 的最佳实践如何助力业务降本提效，如何从入口处建立安全、高可用的防线，如何从 Nginx Ingress 实现平滑切到云原生网关，4.28 将为大家揭晓! 阿里云 MSE 抢购入口： https://www.aliyun.com/product/aliware/mse MSE 国际站购买入口： https://www.alibabacloud.com/product/microservices-engine 点击此处即可观看微服务最佳实践相关视频~ 发布云原生技术最新资讯、汇集云原生技术最全内容，定期举办云原生活动、直播，阿里产品及用户最佳实践发布。与你并肩探索云原生技术点滴，分享你需要的云原生内容。 关注【阿里巴巴云原生】公众号，获取更多云原生实时资讯！
2022-04-21
优秀的个人博客,低调大师

CCtalk高可用多媒体服务技术选型与实现

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81124938 本文来自沪江技术中心开发经理杨福强在LiveVideoStackCon 2017上的分享，并由LiveVideoStack整理而成。杨福强于2012年加入沪江，主要从事教学互动平台CCtalk的开发，今天他将为我们分享高品质教学平台的一些技术难点和解决方案。 文 / 杨福强 整理 / LiveVideoStack 关于CCtalk CCtalk是沪江旗下的支持互动教育平台，它提供网师服务，支持老师签约入驻，拥有基于云，大数据和AI的个性化课程推荐，同时也支持社群化学习，可以通过课前预习，课后答疑和视频回放等来沉淀学习用户，而且还有非常丰富的教学工具，包括实时多向音视频服务，双向白板，屏幕分享，讲义，教学小工具等等。 今天我会从五个方面来给大家介绍： 1，主流直播方案介绍 2，客户端AV引擎 3，服务端架构演进 4，录制回顾以及旁路推流 5，高并发场景案例分析 1、主流直播方案 主流的直播方案，我把它分为四类：RTMP，HTTP-FLV，HLS和RTP 下面介绍一下各自的特点： 1）RTMP RTMP的优点是CDN加速成熟，成本低，可用的开源库，以及开源工具比较多，延迟一般在2到5秒。 2）HTTP-FLV HTTP-FLV的原理是服务器在响应HTTP请求时候，不返回Content-length字段，它使用HTTP协议来实现，不容易被防火墙拦截，延迟略低于RTMP，但都是秒级的。 3）HLS HLS的优点是CDN分发容易，成本低，可以在HTML5页面中直接打开观看，但它延迟一般大于12秒。 4）RTP RTP一般是各家自研，相比于传统的直播方案来讲，自研方案不支持CDN加速，且成本贵，延迟一般是200到800毫秒之间。 2、客户端AV引擎 教育直播-CCtalk是基于RTP协议自主研发的，它的传输层支持UDP和TCP两种方式，支持网师之间以及任意观众之间的连麦互动，连麦延迟和观众延迟都是毫秒级的，同时它支持PPT，白板笔，答题卡，文字等多种不同形式的教学互动。下面介绍CCtalk的软件架构图： 从图中可以看到，所有的客户端与信令系统之间有一个TCP长连接，来实现PPT、白板笔、答题卡、文字聊天等等教学相关的小工具；所有的用户与媒体服务之间有一路TCP或UDP的连接，实现老师与学生之间的双向实时音视频互动，比如说老师上课的时候，将产生的实时音视频数据发送到媒体系统，媒体系统按照一定的路径将媒体数据发送到学生端；如果学生端也上麦了，那么学生端产生的音视频数据也会经过媒体系统转发到老师端，这样就完成了一个教学场景下的双向音视频互动。同时，媒体服务会旁路推流一路RTMP到CDN，学生端可以在HTML5网页里直接观看实时单向直播，这样就满足了在大型直播中网页传播的诉求。另外媒体服务器会将上课时产生的音视频数据发送一路到录制服务，同时信令系统会将上课时产生的PPT、白板笔以及文字聊天等内容发送一份到录制服务，录制服务收到所有上课内容后，将它们以元素的形式存储下来，存储下来的这个格式叫做OCS回顾，便于课后回顾。 因此教育直播架构须具有的以下特性才能满足需求： 而CCtalk就是这么一个支持多种教学工具的实时大规模并发教学平台。在最开始实现这个平台的时候，我们采用了一些开源方案，如webrtc，但后来发现直接使用开源方案无法为完全满足教育直播的需求，因此我们自研发了一套客户端AV引擎： 下面我会针对引擎的网络部分做一个简单的介绍，主要介绍用到的几个关键的技术。首先思考一个问题：当客户端在使用媒体引擎的服务时，需要做的第一件事是什么呢？ 答：需要找一个网络质量较高的边缘节点接入。 如上图所示，假如我们有一百个边缘节点，用户需要从这一百个里面选一个到他的网络质量较高，那么该如何选择呢？可能你首先想到的是DNS解析，但其实只靠DNS解析是不够的，我们还需要一套自动寻路机制，如下图所示： 以小网络为例，它的每次DNS解析的结果可能是变化的，我们无法保证它寻到的结果一定是最优的。当用户接入到边缘节点之后，在使用过程中，用户的网络在不断变化的，因此我们还需要有一个动态检测的机制，如果引擎检测到网络波动较大的情况，那么需要再次启动自动寻路机制，再给它找一个网络质量较高的边缘节点接入。此外，由于网络一直在变化，为了适应这种不断变化的网络，我们还需要一套拥塞控制机制，在这里我推荐Google的GCC拥塞控制算法： 这个拥塞控制可以分为发送端基于丢包的网络估计，以及接收端基于延迟的网络估计两部分，总结下来，就是根据丢包率以及延迟控制发送端的码率。除此之外，当我们的码率开始降低的时候，是不能一直降低下去的，因为码率降低意味着音视频质量的下降。我们还需要另外一套补充机制，叫做消峰处理： 消峰处理的原理是将比较大的数据分成若干个包，在一定时间内发送出去。但这会带来延时的增大，因此需要控制发包的间隔大小。最后，当数据在传输当中由于误码等因素导致丢包时，我们还需要丢包重传的机制来进一步的提升网络的质量。总结下来，其实整个客户端引擎的网络部分，其实就是在做一件事：在实时性与质量之间权衡，而且这个权衡具有一定的自适应能力。 3、服务端架构演进 这张图的上半部分在前面已经介绍过了，就是客户端的引擎部分，下半部分是对应的媒体服务器的一些功能。最初的CCtalk服务系统是由第三方提供的，开发简单，成本低，但确实存在一些问题。后来我们自主研发了一套服务端体系，架构如下： 这个架构分为两大部分：信令系统和媒体系统，整个架构中的所有服务设计功能单一、结构简单，并且所有节点支持线性扩展，理论上它能承载的人数是没有上限的，你只要加机器就可以了，所有的节点支持失效自动转移，这套系统我们用了很长一段时间，但在使用的过程中还是发现了一些问题，以媒体系统为例，首先一个是问题是存在中心节点，这就意味着所有的数据都要先经过代理节点转发到中心节点，再发送到代理节点，最后发送到学生端，并且这个路径是固定的，所有的数据都要走这么长的路径，此外，系统之间有一定的耦合。为了解决这些问题，重新设计了新的媒体架构： 首先，我们把信令系统与媒体系统之间解耦，也就是说他们之间相关的操作如加入房间，建立房间，全部放在客户端的AV引擎去实现；另外，我们去掉了中心节点，加入了转发节点的概念，所有的转发节点都是对等的，并且转发节点会将收到的音视频数据通过一个智能寻路算法自动找一条最优的路径。 整个媒体系统设计原则有两点：一是尽最大的可能找一条最优的路径，将数据尽快的发送到对端；二是在服务出现问题的时候，尽量的保证服务的可用性，并且让用户没有感知。 4、录制回顾以及旁路推流 下面讲一下录制回顾以及旁路推流，架构如下： 具体如下，当 Server收到指令以及数据时，会将音视频数据发送到服务端的音视频引擎，服务端的音视频引擎会对这些数据做一些处理，压缩成一个大视频，将大视频存成MP4，并保存到云端，同时，将这个实时的视频流以RTMP的形式推到CDN，这样，HTML5页面就可以在线观看实时的网页直播；同时媒体录制服务器会将上课时产生的所有内容以元素集合的形式存储一份，我们把这个存储格式叫做OCS。下面就是直播或录播的流程图： 录制OCS回顾视频过程如下： 我们还有一套专门的OCS编辑器来帮助对OCS回顾进行二次编辑，编辑器可以将编辑之后的结果再次传到云端，这样学生就可以观看编辑之后的内容。 在这个过程中，我们使用的转码服务，前期用户量不大的情况下，我们使用CPU转码，单台16核的机器的并发数量可以达到40路，后面随着业务增长，对于转码集群的要求不断增大，所以我们改用了GPU转码，并发情况如下： 5、高并发场景案例分析 高并发场景的案例分析，这一部分与实际的音视频没有太大的关系，但却存在教育场景当中不得不面对的一些问题，我首先举个例子，希望能够对大家有一定的启发。我们来想一个问题：同一个教室里，有20万人同时在听课，我们会遇到哪些问题，我们该如何解决这些问题？假设有20万人在同一个房间，每个人携带的数据量是30字节（例如：用户列表、用户ID、昵称等等），假设每台网关承载三千人，那么至少需要66台网关，正常情况下，假设每秒有800人进出房间，那么负载到每个网关上就是12人每秒的瞬间吞吐，所以算下来当有一个用户进房间，那么他拉取的这个数据量就是45Mb，他进房间的这一瞬间需要拉这么多的数据，每台网关承载的实时的吞吐量是554Mb，当出现异常时，比如说某台网关宕机或者脱离了核心服务，我们的负载均衡服务会将出现的问题的至少三千人负载到剩余的64台服务上，此时的网关负载增量是46.8人，异常时的网关瞬间流量是2Gb。总结下来存在的问题如下： 1）客户端带宽消耗太大 2）进入教室慢 3）服务并发处理量太大 那么，我们的应对策略是： 1） 精简信息+详细信息 2） 提供数据的版本机制，在一定范围内，只处理变化的数据。
2018-07-18
优秀的个人博客,低调大师

主板定制X86嵌入式器件选型

X86是英特尔Intel首先开发制造的一种微处理器体系结构的泛称，包括Intel8086、80186、80286、80386以及80486以86结尾系列，英特尔统治整个CPU产业链长达数十年。但是，Intel以增加处理器本身复杂度作为代价，去换取更高的性能，但集成的指令集数量越来越多，给硬件带来的负荷也就越来越大，无形中增加了功耗和设计难度。 在主板定制开发中如何选择x86嵌入式主板器件呢，下面嵌入式开发公司朗锐智科(www.lrist.com)小编详细介绍： 一．针对芯片组：X86架构的CPU有分为消费类和嵌入式类的，而CPU的三大厂家INTEL,AMD ,VIA 每年针对嵌入式的产品都有固定型号的芯片组推出，因此选择的余地不是很多。差不多选择了品牌，就选择了对应的型号。2010年INTEL主推的嵌入式芯片组就是PINveiw 系列CPU+ICH8M南桥，嵌入式芯片他们本身就是针对瘦客户机这个行业设计的，低功耗，低成本，以及更长的供货周期。而像酷睿双核啊，或者i7等等，都是属于消费类的。 二．针对外围接口的芯片， 1．首先芯片要满足我们的功能需要 2．芯片的总线接口桥片要支持 3．在业界通用而且同样也是刚刚开始推出 4．厂家提供相应驱动 5．价格适中 6．芯片厂家提供良好的技术支持。 三. 针对DC-DC电源控制芯片的选择： 1． 同样芯片满足我们的功能需求：简单而言：就是芯片的输入电压范围满足我们提供的电压，芯片能够产生我们需要的输出电压。 2． 由于电源芯片对系统的稳定性起着关键的作用，对厂家的选择要慎重 生命周期，即可使用年限 价格对比 在价格差不多的时候，我们再在细节上对比电源芯片的各项参数：如电源转换效率，是否集成MOS管，最大过流能力，等等。 X86结构的系统推出已经近30年，在此期间，x86电脑经过飞速发展的黄金时期，用户的应用、软件配套、软件开发工具的配套及兼容等工作，已经到达非常成熟甚至可以说是完美的境界。x86之所以可以赢得市场主要原因在于其是一个十分开放的架构。英特尔与全球大多数的设备生产商的合作在保证了英特尔出货批量的同时，将良品率提升并降低成本从而进一步推高了x86架构在市场的占有率。
2018-05-15

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册