© 2020, Amazon Web Services, Inc. or its affiliates. All ...INNOVAT… · © 2020, Amazon Web...

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AWS 中国（宁夏）区域由西云数据运营AWS 中国（北京）区域由光环新网运营

一个真实的现代化应用改造之旅

黄德滨，AWS 资深解决方案架构师

分会场五：现代应用



日程

• 一个真实的现代化应用改造之旅• 现代化应用改造的动机• 优化应用架构设计• 架构设计时为故障做好准备• 开始改造之旅



应用迁移模式（6R）-- 改造之旅

On-premise

Retain

Retire

Repurchase SaaS on

Rehost Amazon EC2

Replatform

Refactor

Amazon EC2 Auto Scaling

Amazon RDS

Amazon ELB



问题

• 云基础架构带来新的概念• 原有架构的设计不会自动转换为云设计原则• Lift & Shift 通常会限制价值的提升

• 应用不会全面的应用扩展、可用性和成本节约• 云设计原则还在不断完善，但是它是基于原有的可扩展应用设计模式的



传统模式的疼点

• 限制我们优化资源使用率的能力• 限制我们优化性能的能力

• 只能按照“层”来进行扩展• 应用的扩展不是按照业务来进行扩展的

• 应用是按照整体的版本进行部署• 失败就是全部不可用• 扼杀创新和生产力



典型的传统应用：单体架构

User Experience

Business Services

Data Access Layer



一个打车应用单体架构



应用优化的目标

• 迁移到云架构的设计• 对应用解偶，使用微服务来优化扩展、可用性、成本和灵活性• 利用强大各种 AWS 服务来提升价值

• 采用 AWS 最佳实践作为起始点• 提升创新能力



挑战

User Experience

Business Services

Data Access Layer



以云为核心的设计



解偶一个应用

• 功能考量• 数据领域

• 密切性、互相之间的通讯• 内存、CPU 和网络

• 其他非功能因素也能影响解偶• 资源和性能优化• 成本优化• 服务的重用• 可用性模型



弹性的优化

根据内存进行扩展

实例类型：r4.xlarge

根据 CPU 进行扩展

实例类型：c5.xlarge

收银模块税务模块



构建一个服务的框架

• 对于所有服务有一些都需要遵从的核心原则• 服务注册、发现、连接和管理

• 状态管理• 服务元数据• 服务版本• 缓存

• 相同的加速优化• 迭代满足以上需求



使用自动化工具

• 开发和部署经常需要自动化工具来支持• 持续不断的开发和演进这些自动化工具• 使用自动化工具对打包和部署创建共同的标准

• 自动化工具是实现 CI/CD 的基础



应用需要做什么？

• 构建的模式很多，有些简单，有些更复杂• 与您的产品团队一起确定可接受的解决方案，但在短期内，至少应采用一

种简单的方法（最好是停机！）• 第一个方法可能不会成为最终的解决方案，要灵活而富有创意



单体的打车应用

• 单体架构• 业务逻辑• 数据库连接逻辑

• 展现层• 应用集成逻辑

• 一个部署包



我们要做什么？

• 架构设计时考虑冗余• 架构设计时考虑弹性

• 架构设计时考虑可用性• 按服务进行架构设计



微服务化的打车应用

• 根据功能将应用解偶，形成一组互相协作的服务

• 每个服务只实现了很少且关联性很强的一组功能



“Everything fails, all the time”

-Werner Vogels, CTO, Amazon.com



为什么构建弹性应用？

• 基本数学计算可靠性表明，单个故障可能导致大规模的停机• 假设运行依赖于 30 个微服务的应用，每个服务具有 99.99％的可靠性

• 99.9930 = 99.7％的可靠性• 10 亿个请求中的 0.3％= 300 万个失败• 每月停机 2 小时以上

• 但是现实情况通常更糟• 无法消除所有故障

• 减少故障的影响可提高应用程序的整体弹性• 以降级方式运行比完全失败更可取




用户展现界面层

业务逻辑层

数据连接层

组建可用性宕机时间

用户展现界面层 99.9% 8h 45m/年

业务逻辑层 99.9% 8h 45m/年

数据连接层 99.99% 52m 35s/年

合计 99.8% 17h 31m/年




1000 个组件要实现 99.99% 可用性：

每个依赖组建都要有99.9999% 可用性

隔离依赖

或者

组件的失败导致系统性失败组件的失败导致服务降级而不是系统性失败



优雅的降级

• 如果有只读数据库，应用将切换到只读数据库• 应用要维护一个影子应用（shadow），参考 IoT 的做法• 当服务重新上线后重试，参考 lambda 或 greengrass 客户端做法

• 如果内容不可用，它将发送一个通用页面，其中包含一些解释问题的内容



限流

• SOA 系统中的一个常见问题是内部服务的问题而拒绝服务• 一种主要的防御方法是根据上下文来限制（速率限制）传入的请求• 上下文可以是基于用户的或基于源地址的，或两者都可以

• 测量指标必须是所有服务都相同• 它可以使用指数级或斐波那契级时间增长的来实现限制措施

• 可以使用 Amazon API Gateway！



简单的模式

• 快速失败• 安静失败

• 静态后备• 重试



快速失败

• 简单的处理方式是检测到错误后尽快返回错误• 这通常有助于从内存、线程不足等问题中快速恢复

• 当导致错误原因消失后，服务将再次正常运行



安静失败

• 简单的处理方式是自己处理错误但返回成功标识给客户端• 可以是 200 OK 代码，但 Web 服务返回的内容为空• 可以返回成功代码

• 可以简单地安静返回• 当然，仍然应该进行日志记录



静态后备

• 发生错误时返回某种静态的内容/值• 此内容必须是在请求上下文中有意义的内容• 当然，此内容应该是可配置的，而不是硬编码的

if (error)

return static



静态后备的例子



静态后备的实现

VPC

AWS Cloud

Availability Zone 1

Auto Scaling group

Availability Zone 2

NAT GatewayNAT Gateway

Instance Instance

Amazon RDS Master Amazon RDS Slave

Elastic Load Balancing

Amazon Simple Storage Service

(S3)

Amazon Route 53

Secondary

Primary

User

Record Sets

CNAME wwwelastic_load_balancer

Routing Policy = Failover

Record Type = Primary

Amazon S3 Website

Routing Policy = Failover

Record Type = Secondary



重试

• 在 SOA 中，故障通常是短暂的，因此通常一次简单的重试就可以成功• 这是对速率限制（也称为限流）做出反应的常见模式• 如果出错再次尝试，等待一段时间然后再重试

• 使用指数级或斐波那契级增加重试间隔时间• 应该确定最终的错误，不要无限期地重试



更复杂的模式

• 缓存• 阻断器

• 减载



缓存

• 大多数人都知道缓存数据库响应• 可以将相同的方法应用于服务调用

• 通常只需要辨识出缓存的唯一键• 检查缓存，如果不存在或已过期，调用后端，然后在插入缓存同时返回



缓存图解

ServiceCache

Data Source3. 从数据源获取数据

1. 检查缓存

请求

2. 缓存命中或没有命中

4. 插入缓存

响应



阻断器

• 与快速故障模式密切相关• 跟踪故障，然后在超过阈值时执行后备计划（可以是所描述的任何模式）

• 定期检查健康状况以恢复功能



减载

• 来自通信（网络）实现• 一些请求照常通过，其他则返回前面提到的后备模式之一



监控和数据收集

• 这样做的关键是汇总数据以便发现服务错误的趋势• 需要系统事件和事件监视系统

• 拥有这些综合信息将帮助构建更具弹性的系统，并了解应用弱点在哪里



从小做大

• 建立跨职能的小型团队，专注于提供第二层服务• 使这些服务的交付包括将这些服务构建和部署到云所需的所有因素

• 设置基于云的开发环境• 设置持续集成和测试环境• 自动化配置和部署以测试环境

• 最初的重点是这些因素的薄弱的、不健壮的地方• 强调端到端

• 引入可验证 SLA 最低限度概念的测试



检查和应用

• 理解服务的变化是最基本的特征• 确定所有服务都遵从的标准

• 设置较高的自动化和部署标准• 在第一天就建立服务所有权文化

• 不断挑战服务解偶模型• 这些是正确的服务吗？它们是小型且自主的吗？



转型挑战

• 最初的开发通常需要混合环境• 服务自治可能需要一定程度的冗余

• 服务之间的协同通常会暴露太多底层实现• 并行处理服务和自动化通常会为组织带来很大的压力



指导原则

• 不要企图一劳永逸• 集中监控和管理至关重要• 自动化不是一次性

• 不断寻找共同遵循的原则• 忠实于 SOA 核心原则

• 自主性是长期成功的基础

• 解偶不仅仅是功能• 敏捷是根本目标



总结

• 反复迭代，但始终对照长期目标测试您的进度• 解决方案是否优化了资源的使用？• 团队是否有权拥有并发展自己的服务？

• 您的环境是否变得更有生产力？• 您是否能够以更少的约束和更大的敏捷性来构建和发布？



我们希望您在这里找到感兴趣的内容！

也请帮助我们完成投票打分和反馈问卷。

欲获取关于 AWS 的更多信息和技术内容，可以通过以下方式找到我们：

感谢参加 AWS INNOVATE 2020 在线技术大会

微信订阅号：AWS 云计算（awschina）

新浪微博：https://www.weibo.com/amazonaws/

视频中心：http://aws.amazon.bokecc.com/

更多线上活动：https://aws.amazon.com/cn/about-aws/events/webinar/

微信服务号：AWS Builder 俱乐部（amazonaws）

抖音：亚马逊云计算（抖音号：266052872）

博客：https://aws.amazon.com/cn/blogs/china/

AWS 中国账户注册

AWS 全球账户注册

© 2020, Amazon Web Services, Inc. or its affiliates. All ...INNOVAT… · © 2020, Amazon Web...

Documents

Transcript of © 2020, Amazon Web Services, Inc. or its affiliates. All ...INNOVAT… · © 2020, Amazon Web...