黄军雷@云顶云技术团队
TA的个人档案
个人介绍
暂无个人介绍
擅长的技术
- Java
- Python
- 数据库
- C++
- 项目管理
- 自然语言处理
- 敏捷开发
- 架构师
- 开发者
获得更多能力
通用技术能力：
-
Java
中级
能力说明：
掌握封装、继承和多态设计Java类的方法，能够设计较复杂的Java类结构；能够使用泛型与集合的概念与方法，创建泛型类，使用ArrayList，TreeSet，TreeMap等对象掌握Java I/O原理从控制台读取和写入数据，能够使用BufferedReader，BufferedWriter文件创建输出、输入对象。
云产品技术能力：
-
Clouder
-
Apsara Clouder云计算技能认证：超大流量网站的负载均衡
获得于2018-12-31 15:11:53
-
Apsara Clouder云计算技能认证：云存储：对象存储管理与安全
获得于2018-12-31 15:03:57
-
Apsara Clouder云计算技能认证：云数据库管理与数据迁移
获得于2018-12-31 14:55:01
-
Apsara Clouder云计算技能认证：云服务器基础运维与管理
获得于2018-11-26 22:53:07
-
Apsara Clouder云计算技能认证：网站建设：简单动态网站搭建
获得于2018-10-30 12:46:29
-
Apsara Clouder云计算技能认证：超大流量网站的负载均衡
阿里云技能认证
详细说明
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2020-06-17
谈谈测试用例中的前置条件
1.背景 一个测试用例基本要素包括以下 3 点： 前置条件，或者叫被测对象的初始状态 执行步骤 预期结果 在简单模块或单元测试中，大家对于前置条件的理解很容达成共识。但在面对一个复杂系统时，则关于前置条件容易困扰，或是因为可操作性，或是因为可界定性。 2.前置条件的组成 被测对象的程序版本 在测一个库、一个类、一个可执行程序时，版本很容易定义；但面对一个网站时，要说清楚版本不是一件容易的事情。 被测对象的相关数据，包括 数据库里的数据 缓存服务中的数据 队列中的数据 配置文件中的信息 …… 测试环境 测试工具与被测对象的网络拓扑情况 测试工具、被测对象、通讯网络等计算、带宽、存储资源的情况 3.关于被测对象相关数据的准备 极简情况：测试一个类的方法 可以通过构造函数、借助 set 接口等来保证方法调用前，类处在一个确定的状态中。 正常情况：测试一个网站的注册功能 空库的情况下， 第一次执行注册 a 用户 时成功 第二次执行注册 a 用户时反馈失败。 此时都代表网站正常，但两次测试属于不同的测试用例，因为其系统的初始情况不一样。 为了可重复验证测试功能，需要在注册 a 用户，清除掉 a 用户的注册信息，以保证可重入性。此时，注册测试用例的前置条件中的数据要求就是，数据库中没有 a 用户的信息。 正常情况：测试列表的翻页功能 因为数据记录条数不同，导致页面显示的情况会不同。比如说： 空数据 不满一页的数据 10 页的数据 100 页的数据 此时，就需要让数据库里的数据处在不同的数据量情况下，才能进行有效测试。可选的方案包括： 每次测试前，人工清理和准备需要的数据 每次测试前，执行专用的数据生成 SQL（含清理数据） 在数据库里提前生成4 种数据，借助一些其他查询条件来区分。即重点测试翻页功能，其他功能就能用来辅助功能测试。 提前创建4 种数据库快照，按需恢复到需要的数据库状态。 4.说明 离开前置条件来谈测试用例执行结果，很难界定是否真是系统的 bug。 并不需要控制所有前置条件的一致性，一是单个测试用例只与有限的数据相关，二是控制绝对一致的成本很高，不划算。
-
发表了文章 2020-06-16
浅谈面向性能的开发
背景 大部分者开发者入行都是功能实现角度入行，大部分测试人员也是相似的经历。一般项目都是最后时间跟性能较劲，由于系统的复杂性和变更的成本等导致性能工作多数是草草收尾。有没有更好的工程实践呢？有！感谢刚入行的几年的开发工作经历，养成了面向性能、面向稳定性、面向功能的持续开发实践的习惯。现在这里分享给大家！ 定义 本文所谈的开发包括需求、设计、实现、测试，即广义的开发。 面向性能的需求分析 离开业务需求谈高性能容易陷入为技术而技术的陷阱。抛开资源、成本谈高性能则容易导致不必要的项目投入。常规产品、系统除了功能需求外，都会伴随着性能需求。只是因其隐蔽性，导致不是所有的需求提出者都能想到或能给出准确的性能需求。此时就需要系统架构师帮助客户梳理和制定合理的性能需求。性能需求至少包括以下几个角度的信息： 什么场景？ 什么数据量下？ 多大的业务并发情况下？ 多大的计算、网络的资源基础上？ 怎么定义一个性能评估模型？如 TPCC。 面向性能的架构设计 所有架构都有其基础的性能损耗，一方面是性能得以实现的基础，另一方面也是性能上限的瓶颈。 比如引入了缓存就可能比不用缓存的要高性能，但同时引入了数据一致性问题，增加了系统的复杂度和脆弱性； 比如引入的异步处理，增加了反馈的及时性，同时导致原本一次性的操作被分解为多个操作的协同； 比如引入了微服务架构，获取了水平扩展能力，但因增加了服务间调用增加系统性能的损耗。 要逐渐积累一些基本基本组件的性能数据。 如广域网的通讯时间几十毫秒很常见； 比如数据库的读取和写入是有很大的不同； 比如很多系统都有隐式的缓存，如数据库、文件系统。 要知道架构设计的重点之一是平衡各种需求 功能需求 性能需求 容量需求 稳定性需求 可维护性需求 要将系统的性能需求拆解为子系统、子模块的性能需求，比如整体对外需要 1 秒完成数据处理，有代理、计算、存储 3 个环节，则留给计算环节的平均耗时为多少？ 面向性能的系统实现 在很多情况下，系统实现和系统设计是彼此交错的两类工作。在将系统架构落实为系统实现时，要从多个层次来实现系统。一些好的开发实践包括： 在开发过程中，除了设计面向功能测试的单元测试外，还要开发面向性能的测试框架； 构建符合性能测试需求的基础数据； 随着代码的推进，周期性运行性能测试框架，持续跟踪性能劣化的趋势，将其控制在需求范围内； 同样的功能有 N 种实现方式，但性能千差万别，甚至 do while 和 for 都要反复权衡写法。 性能测试与性能优化 性能测试本质上是性能摸底，性能测试不能改变系统的性能，但有助于对系统性能指标、性能瓶颈达成共识。性能测试的设计考验的是技术人员的综合能力。性能测试的执行考验的是技术人员的耐心和细心。性能测试的度量有时会干扰被测对象的性能，如写日志、输出到屏幕、测试数据的累计都可能拉低系统的性能。性能优化的推进需要有系统的视野，不要过早陷入局部优化的泥潭，至少要做好 2 个准备，以形成改进的闭环： 系统分段度量的能力 系统改进度量的能力 性能神话 期望在测试阶段能优化性能 木已成舟，架构是性能优化的天花板，代码是性能优化的约束。 期望性能开发的银弹 从项目角度看，加缓存不一定性价比高；一个系统上的性能开发经验不一定能迁移到另一个系统上，注意场景、资源等的差异。 云顶云（yundingyun.com）是国内首批专注于云计算服务的提供商，致力于“让云计算更简单”。做为阿里云五星授权服务中心，云顶云致力于为企业和政府提供方案咨询、架构设计、部署实施、系统定制、运维托管、技术培训等全方位“4S”级公有云、私有云定制化服务。
-
发表了文章 2020-03-26
面向接口开发的前后端跨团队合作方案
1.问题描述 1.1 背景 大中型产品研发中，由于参与人员过多的原因，手机应用程序、后端服务研发通常会拆分开，由不同的团队负责。这即促进了专业领域的聚焦，又减少了团队管理与沟通的复杂度。 1.2 现象 好现象 内部沟通效率得到提升：手机应用程序、后端服务研发团队内部讨论、传递的信息都是和绝大数人有关的信息；沟通网络效应造成沟通负担得到遏制。 大部分人聚焦内部，少数人做边界沟通，缓解沟通能力的要求。 各自内部迭代速度加速。 坏现象 组织墙阻隔了团队间集体感。 由于缺乏跨组织交流，对合作团队工作认同感降低。 前后端联调滞后，导致项目中后期问题激增，团队氛围恶化，项目延期。 1.3 影响 产品发布节奏放缓。 产品研发成本增加。 技术方案倾向于团队折中、妥协，而非基于产品发展。 2.主因分析 核心原因在沟通阻力增加和利益不一致。 原因 1：沟通阻力增加 术业有专攻，且缺少天天耳濡目染，对跨组织的工作越来越不理解。 因物理和心理两个维度上距离增加，导致小问题得不到及时暴露和解决。如接口的定义、参数的设计、业务逻辑的真正讨论，被延期到集成阶段。 工作排期聚焦内部，对于彼此协调、依赖的事项关注不足。 原因 2：利益不一致 独立 KPI 考核 独立研发计划 前端应用面临海量客户的压力，后端面临多个前端应用需求的压力 3.项目治理方案 建立持续交付的工作模式，以持续交付用户价值为共同目标。 建立跨组织的产品级路线图。 建立以产品经理和系统架构师为核心的跨组织领导体系，拥有决策权和评价权。 后端服务团队的接口人以虚拟角色形式，参与到前端团队的研发管理，包括日会、技术会。 建立面向接口的开发模式。 定期组织跨组织的团队建设活动。 4.实施方案 4.1 组建阶段 明确授权产品经理、产品级架构师 统一研发基础设施，包括接口设计与发布流程 统一沟通工具，制定沟通计划 统一迭代节奏 4.2 实施阶段 保持后端团队代表的有效参与前端团队，需产品经理、架构师监督。 保持按节奏持续发布至测试环境，包括前端、后端，让问题在有限时间内得到暴露和解决 4.3 接口开发技术 方案一：基于 Swagger 基于接口设计、描述框架 Swagger （https://swagger.io/），构建基于接口的研发流程。 后端服务即 API 文档，前端团队清晰了解接口能力，利于持续集成。 后端持续发布接口能力，简化 API 文档维护成本。 需要前后端团队遵循开发流程，提高项目的整体效率，而非单次沟通效率。 Swagger - Simplify API development for users, teams, and enterprises with the Swagger open source and professional toolset. Find out how Swagger can help you design and document your APIs at scale.by https://swagger.io/ （1）接口设计阶段 针对业务需求清晰的接口，即通过规划的接口，启动基于Swagger的接口设计。 侧重基于真实服务代码描述接口设计 不做功能的有效实现 将设计通过的接口，发布到测试环境，供前端团队查阅和开发联调 接口设计规范：OpenAPI Specification https://swagger.io/resources/open-api/ 接口设计工具：Swagger Editor Design, describe, and document your API on the first open source editor fully dedicated to OpenAPI-based APIs. The Swagger Editor is great for quickly getting started with the OpenAPI (formerly known as the Swagger Specification) specification, with support for Swagger 2.0 and OpenAPI 3.0. https://editor.swagger.io/ 使用Yaml语言, 定义好API接口 点击 generate server code, 选择需要的语言, 即可下载自动生成的相关接口的初始化项目 点击 generate client code, 选择需要的语言, 即可以下载自动生成调用这个接口的客户端代码 接口定义查看工具：Swagger UI Swagger UI 可以将项目接口自动生产具有交互的html页面, 是一个前端页面的自动生成项目. Swagger UI的 demo见: swagger ui demo. （2）接口实现阶段 按节奏逐渐实现接口的能力。 对于已实现的能力，要清晰描述能力 对于在在研的能力，要描述清晰状态 后端服务工程引入swagger的依赖 <dependency> <groupId>io.springfox</groupId <artifactId>springfox-swagger2</artifactId <version>2.7.0</version> </dependency> <dependency> <groupId>io.springfox</groupId <artifactId>springfox-swagger-ui</artifactId <version>2.7.0</version> </dependency> 生成API的server stub和client SDK Swagger Codegen can simplify your build process by generating server stubs and client SDKs for any API, defined with the OpenAPI (formerly known as Swagger) specification, so your team can focus better on your API’s implementation and adoption. （3）接口设计变更 后端人员无需关注Swagger描述文件和接口文档，有需求变更导致接口变化，直接写代码就好了。把调用层的代码做个修改，然后生成新的描述文件和接口文档后，给到前端即可。 方案二：基于阿里云 API 网关 https://www.aliyun.com/product/apigateway API 网关（API Gateway），提供API托管服务，涵盖API发布、管理、运维、售卖的全生命周期管理。辅助用户简单、快速、低成本、低风险的实现微服务聚合、前后端分离、系统集成，向合作伙伴、开发者开放功能和数据。https://www.aliyun.com/product/apigateway 提供防攻击、防重放、请求加密、身份认证、权限管理、流量控制等多重手段保证 API 安全，降低 API 开放风险。 提供 API 定义、测试、发布、下线等全生命周期管理，并生成 SDK、API 说明文档，提升 API 管理、迭代的效率。 提供便捷的监控、报警、分析、API 市场等运维、运营工具，降低 API 运营、维护成本。 API 网关功能 API 生命周期管理 支持包括 API 发布、API 测试、API 下线等生命周期管理功能。 支持 API 日常管理、API 版本管理、API 快速回滚等维护功能。 全面的安全防护 支持多种认证方式，支持 HMAC (SHA-1，SHA-256) 算法签名。 支持 HTTPS 协议，支持 SSL 加密。 防攻击、防注入、请求防重放、请求防篡改。 灵活的权限控制 用户以 APP 作为请求 API 的身份，网关支持针对 APP 的权限控制。 只有已经获得授权的 APP 才能请求相应的 API。 API 提供者可以将调用某个API 的权限主动授予给某个APP。 若 API上架到 API 市场，购买者可以将已购买的 API 授权给自己的 APP。 精准的流量控制 流量控制可以用于管控 API的被访问频率、APP的请求频率、用户的请求频率。 流量控制的时间单位可以是分钟、小时、天。 支持流控例外，允许设置特殊的 APP 或者用户。 请求校验 支持参数类型、参数值（范围、枚举、正则）校验，无效校验会被 API 网关直接拒绝，以减少无效请求对后端造成的资源浪费，大幅降低后端服务的处理成本。 数据转换：通过配置映射规则，实现前、后端数据翻译。 支持前端请求的数据转换。 支持返回结果的数据转换。 监控报警 提供可视化的API实时监控，包括：调用量、流量大小、响应时间、错误率，在陆续增加维度。 支持历史情况查询，以便统筹分析。 可配置预警方式（短信、Email），订阅预警信息，以便实时掌握API运行情况。 自动工具 自动生成 API 文档，可供在线查看。 API 网关提供多种语言 SDK 的示例。降低 API 的运维成本。 提供可视化的界面调试工具，快速测试，快速上线。
-
发表了文章 2020-03-18
基于OAuth2的跨网站统一登录解决方案
1.需求场景 随着业务发展，一个企业开发、运营了多个网站，同时也产生了一些亟待解决的问题。 用户使用每个网站前，需要重复注册，需要记住对应的账号和密码。 用户使用每个网站时，需要一次次重新登录。 用户只是了解一个个独立的网站，企业没有在用户心中形成统一的形象。 每个产品都需要重复设计、开发和维护注册、登录等模块。 用户的信息分散在各个网站中，不利于更好的了解用户。 2.解决方案 2.1 方案说明 本解决方案基于OAuth2 协议，为网站用户提供跨网站的流畅登录体验，且拥有高性价比的弹性伸缩能力。 统一认证中心：基于 Spring Cloud Security、JWT、OAuth2 协议，提供统一认证能力，负责用户认证数据的统一管理。 需接入的网站：基于 SSO-SDK，轻量级接入统一认证体系，与统一认证中心协作，提供用户畅游企业各产品网站的最佳浏览体验。 管理中心：负责管理需接入网站的认证管理，保证统一认证体系的安全与可控。 关于用户的登录页，为保证用户的统一体验及统一企业品牌，推荐采用统一登录页的方案，同时支持少数网站需要自定义的特殊需求。 基于微服务+阿里云容器服务，提供高性价比的弹性伸缩能力。 2.2.方案优势 遵循主流的OAuth2开放协议，除能打通内部系统的用户数据外，还可在授权允许情况下，允许外部系统使用本系统的用户进行登录，如常见微信登录、QQ登录等。 Spring Security 框架技术成熟且社区活跃，稳定性有保证。 在Spring Security 框架基础上，进行增强扩展，可满足密码模式下的sso场景。 支持跨域单点登录。 基于阿里云基础设施的构建，整体系统稳定可靠。 充分发挥阿里云的弹性伸缩能力，即可控制成本，又可适应用户数量的爆发式增长。 兼顾私有云、传统 IDC 部署环境，满足不同客户的运行环境的需求。 3. 客户价值 基于此方案，帮助企业打通各产品的用户体系，且实现多种场景下的免登。企业拥有企业级的统一账号体系，建立统一企业品牌，提升用户注册与登录场景的体验。 统一的用户认证体系，实现统一认证、跨网站免登，实现 SSO。 统一的用户数据库，实现用户数据的聚合，帮助企业更懂用户。 企业级网站的统一登录页，统一品牌形象，统一用户体验。 支持产品根据特殊性选择自定义登录页。 支持用户名、手机号、邮箱等多种认证方式的扩展。 3.1 网站用户的收益 一次注册即可使用所有企业运营的产品，无需反复填写注册信息 一次登录即可所有企业运营的所有产品，即安全又便捷 3.2 企业的收益 降低用户试用企业运营产品的门槛，利于交叉营销。 减少用户反复登录，利于产品用户促活。 减少产品研发中的重复建设，降低成本，提升产品推进效率。 统一建设认证中心，便于统一和提升所有产品的账号安全。 4. 关于登录页的说明 4.1 模式一：统一登录页的SSO 此种模式无需网站实现登录页、登录接口的开发，未登录状态的用户会自动被引导到统一认证中心去登录。 4.1.1 实现原理 4.1.2 说明 技术实现整体使用spring-securiry-oauth2的 “授权码模式” 来进行实现。 4.2 模式二：网站自定义登录页 4.2.1 实现原理 4.2.2 说明 在统一认证中心与网站的实现上，除spring-securiry-oauth2之外，还需要引入云顶云研发的 “密码模式SSO” 扩展包来进行实现。 云顶云（yundingyun.com）是国内首批专注于云计算服务的提供商，致力于“让云计算更简单”。做为阿里云五星授权服务中心，云顶云致力于为企业和政府提供方案咨询、架构设计、部署实施、系统定制、运维托管、技术培训等全方位“4S”级公有云、私有云定制化服务。
-
发表了文章 2020-02-20
战疫情，云顶云新概念公益项目手记
1、项目背景 2020年的春节被新型冠状病毒感染肺炎疫情蒙上了一层阴影，看到疫区医院IT运维志愿者的召集令以及各地同行纷纷动手开发系统为国家尽力时，我司（天津云顶云科技有限公司）作为行业的一份子，也想在这个特殊的时期做点什么，贡献自己的一份力量。 在这个时候，我们接到了合作伙伴外语教学与研究出版社的电话。原来，为了积极响应政府和教育部门“停工不停学”的号召，伙伴决定将旗下的《新概念英语》免费向社会开放，希望我们能给予技术上的支持，能尽早上线，帮助广大学生在疫情期间依然能有机会学到最好的知识。 在就产品需求、技术方案、人员情况、当地疫情等多方面的全面评估后，我们决定一起用技术奉献社会，用最短的时间完成这个公益项目的上线，并确保它能够平稳运行。 2、项目分析 2.1 时间紧 团队虽然年轻，干劲却很足，给自己立下了FLAG：从研发到上线，赶在96小时内完成目标！既然做了决定，我们就这样如火如荼地开始了紧张刺激的冲刺96小时。 2.2 压力大 结合相关的数据与经验，我们初步预估项目上线后的冲量峰值压力将会是上线前的20倍左右。 后来的实际情况也证实了这一点，2月4日上线当天，瞬间涌入的峰值压力是上线前平均值的19.4倍。因此，如何筑起高墙大坝，扛住突如其来的流量洪峰，是我们要面对的第一个难题。2.3 协作难 由于春节期间很多同学都回老家过年，项目相关的成员分散在北京、天津、山西、福建等全国各地，这也是我们团队第一次展开这么大规模的远程协作，很多问题一下子凸显了出来： 网络的问题：尤其有的同学在农村，网络不太稳定，有时信号一断只能干着急。 联调的问题：平时在公司通讯基本靠吼，或者探身看下屏幕就能了解情况，现在只能靠不停的码文字、语音、电话...... 项目管理的问题：时间紧任务重，现在只能倒排计划，就像一面开车、一面查目的地的情况... 没想到因缘际会，使我们团队可能成为了全国最早远程复工的那一波人之一 >_< 2.4 测试难 由于事发紧急，只能一边研发一边测试，这样的方式对于我们这样有着DevOps经验的团队来说倒也不是太大的难事，只是有一点比较麻烦：扛住巨大的流量压力是整个项目中最为关键的一环，如果不能做到万无一失，即使万事俱备也有可能功亏一篑。因此，我们不仅需要做足够的压力测试，还要做到严格、靠谱的压力测试；我们不仅要在测试和预发环境上做压力测试，还要在生产系统上做压力测试；我们不仅要在白天边研发边测试，还要在夜深人静压力位于谷底时在生产环境上滚动更新做压测，验证功能、查找问题、参数调优等一通操作猛如虎，然后再回滚回来确保白天用户正常使用... 3、冲刺96小时 伟人说过，一切敌人都是纸老虎。与困难狭路相逢，勇者胜！团队没有二话，只有一个字：干！ 3.1 打磨需求，不放过每个细节 这个文案与这次公益行动不符，要改！这个不容易理解，要改！正向需求验证没问题，既有的系统功能呢？要验证！前台交互没问题，后台日志系统是否有影响？要分析！对其他依赖的第三方应用是否有影响？要保证兼容性！…… 3.2 持续优化，力争做到万无一失 流量增加 50%能不能抗住？流量翻倍能不能抗住？流量数十倍增加能不能自我保护？能不能动态扩容抗住压力？能不能减少流量抖动带来的不必要的弹缩？流量模型是什么样子？流量会聚集在哪个瓶颈点上？各个突发情况下，除了自动化机制外，还有哪些其他的应急措施？在这样追问、讨论中，大家不断深入思考；在各种压测数据中，大家不断探求优化的思路和可能。为了不影响既有用户的访问，所有的压测都集中深夜；为了获得真实的一手数据，敢于直接压测生产环境（这也得益于系统的鲁棒性强）。 3.3 胜利会师，圆满完成任务 连续作战 4 天 4 夜，不只 96 小时 持续发布 7 版，不断迭代完善 流量激增19.4倍，扛住了！ 钉钉语音会议 30+ 次 参与的同学 20+ 名 4、解决方案 总结起来，该公益项目能快、准、狠地完成，主要得益于以下几个方面： 项目采用了微服务架构，模块之间耦合度较低，新功能上线可滚动发布，加上团队具备DevOps能力，因此保质保量地完成了研发任务。 项目完全基于阿里云的容器服务ACK构建，同时得益于阿里云强大而全面的产品矩阵来加持，使整个项目的稳定性、可靠性上更上了一层楼。 除了阿里云强大的容器服务以外，我们也用到了大量的其他产品如OSS、CDN、PTS等，强大而且全面的阿里云是本项目成功上线的幕后英雄。最终，我们利用阿里云的若干产品完成了如下方案： 这个方案具有以下特点： 应用容器化部署，享用云原生容器组资源编排能力 优化容器组集群计算资源，集群稳定性高 利用弹性伸缩以及抢占式实例，弹性低成本 解决自建集群快速扩容困难问题 内容分发网络CDN有效分担源站压力，避免网络拥塞，确保在不同区域、不同场景下加速网站内容的分发，提高资源访问速度。 4.1 方案解读：两级弹性伸缩 由于流量洪峰的不确定性（不确定什么时候到来，不确定最终的压力有多大），同时还要考虑到财务的可行性，不惜一切代价是态度，但不能作为工程实践的指南，要让花的每一分钱都有价值。因此我们最终采用两级弹性伸缩的策略： 利用ESS对整个集群进行弹性伸缩，ESS是阿里云推出的可以自动调整弹性计算资源的服务，可以根据业务需求和策略设置伸缩规则，在业务需求增长时自动为您增加ECS实例以保证计算能力，在业务需求下降时自动减少ECS实例以节约成本。 设置ESS：当CPU平均使用率达到75%或内存使用率达到80%时，会向K8S集群中添加两台ECS，以提高系统整体的服务能力。 利用K8S的HPA机制对容器资源进行弹性伸缩，最大限度利用云资源的水平弹性。HPA是实现水平伸缩的控制器，它能在当POD中业务负载上升的时候，创建新的POD来保证业务系统稳定运行，当POD中业务负载下降的时候，可以销毁POD来提高资源利用率。 设置HPA：当CPU平均使用率达到70%或内存使用率达到80%时，会水平扩展POD数量，以提高热点服务的能力。 4.2 使用HPA趟过的坑 在使用HPA的过程中，我们也遇到了一些问题，虽然历经一些波折，最终也顺利解决，这里一并记录。 问题1：在压测过程中发现，POD分布不均匀，相互间存在资源争抢的现象，导致服务器资源富裕而性能提升不上去的情况。解决办法：对于资源消耗较高的服务使用硬性反亲和，资源消耗相对较低的使用软性软亲和方式可以有效利用服务器资源，提高整体系统性能。 问题2：POD的CPU和内存的基准值配置错误，导致使用率始终超过弹性伸缩的阈值，POD直接弹缩到最大值。解决办法：调大request值，将使用率控制在HPA值之下。 问题3：POD启动消耗的资源较大，启动瞬间会将POD数量弹至最大值，从而导致整体资源使用率过高。解决办法：等服务启动稳定后再配置HPA规则即可解决。 4.3 方案解读：利用PTS进行专业准确的压力测试 PTS是阿里云推出的云化测试工具，是项目中压力测试的好帮手。它可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。通过较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量最佳配比。 利用PTS，我们进行了100多轮不同接口不同规模的压力测试，快速地定位问题、解决问题和回归验证，是项目压力测试的绝世神器！通过这些压测实践，我们也总结了一套关于压力测试的心得： 根据接口需要达到的并发，来进行首次递增式压测，来查看目前接口能达到多大的并发。 压测完成后，查看压测数据，查看RDS，ECS，Reids等监控，从资源方面入手来查找瓶颈，来查看是否是连接数设置的问题，还是资源性能问题。 从架构方面来进行排查，从底层一步一步来排查。先将直接压接口，看看接口能达到多大 并发，然后在加上SLB来压测，来看是否是服务配置问题。 4.4 使用PTS趟过的坑 问题1：使用PTS压测时发现来源IP过于集中，如何能让压测数据更有可信度？解决办法：经优化，选择了扩展来源IP和指定地域配置来进行压测，从而实现压测数据的可信性。 问题2：模拟大量客户注册登录，最开始创建的压测创景是只使用一个账号密码来进行反复登录，也存在压测数据的可信度问题。解决办法：后来经优化场景，采用自定义参数，随机生成一些数据库中没有的账号，来进行传参，更真实的模拟了用户登录场景。 问题3：不通时间段，同一个接口压测结果相差较大。解决办法：在压测的时候有时候可能会有网络抖动，影响压测结果，同样的接口，在没有任何修改的情况下，白天和凌晨压测的结果，相差较大，白天TPS相对要高一些。由于客户的正式站不能在业务繁忙的时候进行压测，所以将测试站配置对齐正式站，选择客户业务繁忙时间，来进行压测测试站，最后来和正式站压测数据对比。PTS的报告十分直观，信息也很详尽。 4.5 方案解读：利用CDN分发加速减轻源站压力 由于终端用户分布在全国各地，但课程的音频资源放在阿里云的华东2地域（上海），距离较远的用户在使用过程中就会出现较高的延迟。为了解决这个问题，我们引入了CDN。利用CDN分布在各地的边缘节点，有效分担源站压力，避免网络拥塞，确保在不同区域、不同场景下加速网站内容的分发，提高资源访问速度。 5 项目总结 紧张刺激的96小时，通过伙伴外研社团队、云顶云团队和阿里云的精诚协作，最终顺利完成，上线后用户好评如潮，我们也在全国共克时艰的时候，为抗击疫情贡献了自己的一份微薄之力，也为云顶云在云原生、微服务的探索之路上添加了重要的一笔。以不远的将来，云顶云将继续秉持“让云计算更简单”的理念，立足于阿里云强大的技术与生态，服务更多用户，为祖国蓬勃发展的互联网事业继续贡献自己的力量。
滑动查看更多
2020年06月
2020年03月
2019年11月
-
11.26 09:02:56
发表了文章
2019-11-26 09:02:56
云计算时代 Java 运行时不止 JRE
云计算时代 Java 运行时不止 JRE -
11.21 08:58:05
回答了问题
2019-11-21 08:58:05
Java基础测试题|挑战你的底线
c++ 程序员飘过，
赞0 踩0 评论0 -
11.19 08:47:55发表了文章
2019-11-19 08:47:55
基于云计算的极速产品研发效率
基于云计算的极速产品研发效率 -
11.05 00:04:49发表了文章
2019-11-05 00:04:49
关于引入开源技术的一些建议
关于引入开源技术的一些建议 -
11.04 09:07:56回答了问题
2019-11-04 09:07:56
阿里云开发者社区招募首批问答官
支持
赞0 踩0 评论0
滑动查看更多
-
发表了文章
2020-09-18
致莅临云栖大会百城汇嘉宾们的感谢信！
-
发表了文章
2020-06-17
谈谈测试用例中的前置条件
-
发表了文章
2020-06-16
快捷编制面向项目的资源采购计划
-
发表了文章
2020-06-16
浅谈面向性能的开发
-
发表了文章
2020-03-26
面向接口开发的前后端跨团队合作方案
-
发表了文章
2020-03-18
基于OAuth2的跨网站统一登录解决方案
-
发表了文章
2020-03-11
计算机时间问题漫谈
-
发表了文章
2020-02-20
战疫情，云顶云新概念公益项目手记
-
发表了文章
2019-11-26
云计算时代 Java 运行时不止 JRE
-
发表了文章
2019-11-19
基于云计算的极速产品研发效率
-
发表了文章
2019-11-05
关于引入开源技术的一些建议
-
发表了文章
2019-10-15
“敏捷”导引
-
发表了文章
2019-09-25
同行相聚 共话未来 - 阿里云 MVP2019 全球闭门会参会记
-
发表了文章
2019-04-15
如何只克隆部分代码？
-
发表了文章
2019-02-19
CMake 入门2/5：第一个程序 helloworld
-
发表了文章
2019-02-01
如何基于 Markdown 编写技术文档
-
发表了文章
2019-01-30
CMake 入门1/5：基于阿里云 ECS搭建体验环境
-
发表了文章
2019-01-17
Oracle字符串数据类型简述
-
发表了文章
2019-01-16
Scrum实践：每日站会
-
发表了文章
2019-01-13
敏捷框架Scrum的核心要点（“3355”）
滑动查看更多