微软Azure学习总结---电商架构深度解析及架构设计

本周参加了微软Azure的课程学习，总结如下：

电商架构深度解析及架构设计

1. 电商的机会分析

初创起步阶段：

云平台前期资金的要求低，使用方便，容易扩展，基本上是这部分公司的首选平台。

Azure的公网IP资源，带宽资源和VM资源能够很好的满足他们的技术需求。

Azure的PaaS服务和CDN服务可以提供系统平台的快速搭建。

如果是跨境电商，Azure云能够提供更好的国际化服务。

规模化运营阶段：

Azure支持混合部署的能力，可以快速提供相应的公网带宽资源，计算资源和服务。比如前台和中台的一些应用可部署在Azure上。

Go global的应用场景。

Azure丰富的微服务部署能力和DevOps工具。

Azure inftrastructure as code的能力帮助他们实现自动化。

大数据和IOT相关的PaaS服务可以助力业务实现智能化。

稳定发展阶段：

关注新项目，从新系统和新项目着手。

Go global的项目。

大批量的并行计算资源。

系统的混合部署，容灾或双活部署。

安全开发体系的规范和能力的输出

机器学习和AI服务的提供和能力的输出

2. 电商系统面临的挑战

资源的弹性变化 ，应用系统的灵活伸缩

基础架构的高可用，应用系统的高可用

系统自动化，业务智能化，大数据运营

系统和数据的安全性

3. 电商系统主流架构的演进

升级改造前：

单体应用

多个团队负责，责任不清晰

代码复杂，管理性差

代码升级复杂，工程量大

代码部署成为瓶颈

扩展困难

错误排查很困难

升级改造后：

微服务

一个团队负责分工明确，责任明晰

易于采用新的技术，快速迭代

可快速部署

可单点扩展，灵活高效

易于自动化

4.云上应用架构重要原则

假定任何服务都可能失效

NIC，VM，网络，应用，系统，区域都可能失效；

故障注入，主动测试；

面向弹性设计，系统解耦

横向扩展能力，充分利用冗余性无态化改造；

使用Queue， BlobQueue, Service Bus, Event Hub进行解耦

计算和存储分离

构建统一唯一的数据源：Blob服务;

采用多种数据存储技术

重视工具和自动化流程

程序化所有的事情，可编程ARM；

自动化所有的事情，运维层面，业务层面

5. 服务提供应的开发部署建议

发布监控指标，服务的状态透明化；

无态化，可横向扩展；

支持幂等性操作

保护自己，实现安全验证；

实现高校的流量控制机制；

对故障进行隔离；

隐藏服务的实现细节，只暴露简洁的接口。

保持向后的兼容性；

对API进行的版本管理，能够在API升级时及时通知消费者。

6. 服务消费方的开发部署建议

面向假定失效来设计

考虑当被限速或截流时的措施

良好的重试机制，包括带有数回退机制的重试策略

优雅的降级，保证核心功能的SLA

在高峰期要快速的失败，节约宝贵的系统资源

尽可能的使用缓存来提升性能

客户端的负载均衡机制

7. 微服务的服务发现

基本要求：可以使用DNS，而不是IP来命令和访问服务

采用动态服务注册服务

Etcd：高可用，分布式的key-value存储，用来共享配置和服务发现。

Consul：发现和配置服务的工具，可以执行监控检测来实现服务的高可用。

Zookeeper：常用的，为分布式应用设计的高可用协调服务。

Eureka：服务注册表，提供了REST API的注册和查询功能。

8.Azure上部署微服务建议

管控模式：不同的微服务部署在不同的资源组下面；同一个资源组只部署一个微服务的多个实例

部署选项：

IaaS：VM, Azure AppService，自选机型，服务托管，可自动伸缩

PaaS：Container Service，Azure Service Fabric, 模板化管理，自动编排调度，秒级部署

SaaS：Azure Fuctions(国内暂未上线)，API Management，完全托管,自动伸缩，秒级部署

VM/APP服务/容器：

每个VM/APP服务/容器部署一个服务

独立的管理，管理权限明确；独立扩展；独立部署；独立升级；可支持不可变的部署方式

API management：

使用API management来作为微服务对外的出口，特性：安全验证、流量控制、数据缓存、版本管理、性能监控、事件日志、混合部署。

基于VM的部署建议

每个微服务可部署在一个resource group中，所有资源保持同一生命周期；

每个微服务可以考虑采用单独的负载均衡服务。

每个微服务的Tier部署在单独的可用性集中，这样可以保证每个Tier的可用性；

建议使用每个微服务采用单独的存储账号，如果使用Unmanaged Disk应该考虑20000IOPS的容量单元

对外的部署部署在Public的子网，其它的部署在Private子网

可考虑NSG等安全措施的部署

9. Azure相关负载均衡器说明

Azure Load Balancer：四层的负载均衡器，对于微服务部署在VM、Service Fabric、 ACS中的场景，可提供基于IP和端口的负载均衡功能。

Azure Application Gateway：七层的负载均衡器，可提供基于URL Path模式的流量负载均衡模式，可以和Azure Load Balancer配合使用，ALB后端，构建二级的负载均衡系统。

Azure Web Apps: Azure Web App本身已经为微服务提供了负载均衡的功能。另外，也可以用采用内置的ARP配置基于URL Path的反向代理。

Azure Service Fabric：Service Fabric已经对部署在其上的微服务提供了基于IP和端口的负载均衡能力，如果不同的服务需求监听同一个端口，比如80端口需要服务两个不同的服务IP:80/cart和IP:80/order，可以使用OWIN Listener来实现这个功能。

ACS：对于DC/OS，默认已经配置了Azure Load Balancer，同时也可以配置其自有的Marathon Load Balancer进行集群内部的负载均衡，对于Kuberenetes，由于在集群内部已经使用了Kube-proxy作为service的负载均衡组件，可以将服务类型配置为LoadBalancer，从而将Azure Load Balancer作为外部的负载均衡器。

10. 微服务架构问题以及措施

雪崩效应

现象：微服务之间相互依赖，服务链中单个服务由于出现各种原因导致请求响应慢，随着响应请求的累积造成该服务不可用，进而影响整个系统，造成大面积的服务不可用现象。

措施：

超时机制，避免超时请求占用系统资源

熔断机制，产生大量未能正常处理的请求，则可以熔断该服务的调用，快速释放资源

隔离机制，物理隔离、线程隔离来对服务进行隔离，避免相互之间的干扰

IO放大问题

现象：由于微服务之间相互依赖，一个请求可能会依赖一条服务链，前端等待一条请求可能在后端成倍的放大。

措施：

客户端缓冲(缓存）

热点问题：

现象：在处理一个请求的过程中，可能需要调用几个相应的微服务，而这些微服务有可能同时依赖某一公共服务，这样就会导致这个公共服务成为热点，成为系统的瓶颈。

措施：在向下游请求时，携带必要的信息，使整个请求链接只有第一次依赖会去请求公共服务。

日志追踪问题：

现象：在处理一个请求的过程中，可能需要调用几个相关的微服务，日志记录很分散，如果出现问题，很难进行全链路的追踪和定位。

措施：针对每次请求创建全链路的唯一ID，实现方式有：zipkin与dapper

11.微服务的解耦模式

消息队列:Azure Service Bus 保证顺序，至多一次，至少一次；Azure Service Bus可在分区的基础上保证消息的顺序，支持事务性消息，重复消息检测，可以简化实现过程。

12.微服务之间事务管理和数据一致性

典型方案：二阶段提交，强一致性方案，通过事务性消息来确保事务。

简化版方案：将需要跨微服务同步的数据库放在一个实例中，增加一个存放消息的库。利用数据库的XA Transactions的支持进行跨库的事务处理。仅适合数据库操作场景，不适合RPC操作场景。

方案三：通过DDD的Event Sourcing和CQRS来解决，通过一个业务用例对应一个事务，一个事务对应一个聚合根，也即在一次事务中，只能对一个聚合根进行操作。

13. 微服务和Azure的组合优势

资源按需供应，热点资源可动态扩展

基础架构即代码，结合资源组可进行全生命周期管理

系统之间依赖性低，可扩展性和可用性较高

可用Server-less架构

14.电商秒杀系统参考架构

秒杀系统实际是限流系统，拦截低质量的流量，将高质量的流量放入到后台处理

主要模块：

Gate Keeper：接受客户请求，将用户请求发送到后端做相应的处理，并将结果反馈给用户端

Safe Protector：防刷服务，过滤IP和客户ID。可实现准时处理，动态增加黑名单

Policy Controller：业务规则过滤，例如可以根据用户级别和商品编号对可购买的商品种类和数量进行限制。

Inventory Manager：管理秒杀环节的库存情况，通常库存都是在秒杀开始之间单独导入用于秒杀的商品和库存。

Shooping Cart：将商品将入购物车，通过Safe Protector， Policy Controller和Inventory Manager验证的用户请求将会成功的将商品加入购物车

Safe Protector 实现动态防刷：

数据获取：Gate Keeper将日志打入Azure Event Hubs

数据处理：由Azure Stream Analytics或storm从Event Hubs读取数据，并写入Azure HDInSight进行计算处理。

黑名单的动态加入：有单独的worker进程将HDInsight计算的新的黑名单加入Safe Protector的缓存数据库中。

新的请求校验：新的请求将会按照更后的黑名单库进行验证。

为什么Azure Redis会适合这个场景？

Redis的key有失效时间设定，与超时不下单自动清空购物车场景契合。

Redis支持Hashes的数据格式，支持商品的快速存读；且商品之间的数据schema可以完全不同，对应商品的不同特性。

防刷服务中需要统计快速有效的Unique ID/UID的访问次数，可采用Redis的Sorted set来快速实现。

Azure Redis是托管的PaaS服务，易于扩展，可实现集群部署，自动分片，可实现跨区域复制。

为什么Azure DocumentDB适合这个场景？

Document DB支持不同的一致性级别（可以细化到每个查询）和服务器端的事务处理，可以适用于许多场景。

不同商品不同品类的属性是完全不一样的，属性的数量和名称可能是完全不一样的，传统的数据库方式会存在性能、扩展、灵活性上的问题。 Document DB支持Schema less方式。很好的支持EAV模式，可以通过内置的Json数据结构简单高效的解决该问题。

爆款商品的数据操作，会对爆款商品的数据所在分区成为热点和瓶颈，影响系统整体性能。Document DB可以通过合理的设置partition key，将产品的数据拷贝合理的分散到多个shard，从而消除热点。

Document DB有非常强大的索引功能，可以自动创建基于JSON内容的索引，可以根据不同的商品属性实现人性化的搜索与过滤。

Document DB读写性很好，P99的单独的读操作的响应时间在10ms之内，而且性能是可配置和可扩展的。

15. 电商系统的首页展示架构

CDN + Load Balancer + Azure Storage Blobs + 页面更新服务 + 数据更新服务

16. 电商离线推荐系统参考

日志数据：

flume, logstasjh, fluentd进行日志收集，频率基于分钟或者小时，直接存储到azure Blob Storage.

Azure Blob storage 可作为唯一的全量数据的核心存储源，实现计算和存储的分离。实现HDInsightr Hadoop集群的单独自由的伸缩，升级和维护。

Azure Blob storage 和Hadoop深度集成，在Hadoop集群中使用“WASB://”即可直接访问Azure Blob Storage，和访问HDFS一样方便。

Azure Blob storage支持Append Blob，参考工具：blobfs

结构化数据：

可采用Sqoop进行数据的抽取，数据可存储在Hbase，Hive或SQL中。

推荐系统的目标：

推荐系统是电商精细化运营的核心平台，是实现千人千面的基础，推荐系统是最终目标就是提升流量 的转化率。

推荐系统的技术特点：

推荐算法的有效性要求高

实时性要求高，一般要求在1秒内完成推荐

系统复杂，涉及从数据摄入到展现的各个环节

推荐算法：

主要有Content-Basesd Filtering 和Collaborative Filtering。在电商中主流的推荐算法都是在Collaborative Filtering的基础上做的改进和优化。 Collaborative Filtering有两种方法：User-Based和Item-based

二、Azure网络实验

这部分主要是根据操作手册来对Azure的网络配置进行操作，操作手册在附件中， 主要有八个实验，这里总结一下实验中的一些基本概念：

1.Azure VNET

Azure 资源可以通过 Azure 虚拟网络服务与虚拟网络中的其他资源安全地通信。 虚拟网络是你自己的网络在云中的表现形式。 虚拟网络是对专用于订阅的 Azure 云进行的逻辑隔离。 可将虚拟网络连接到其他虚拟网络，或本地网络。

2.Azure NSG

网络安全组 (NSG) 包含一系列安全规则，这些规则可以允许或拒绝流向连接到 Azure 虚拟网络 (VNet) 的资源的网络流量。 可以将 NSG 关联到子网、单个 VM（经典）或附加到 VM 的单个网络接口 (NIC) (Resource Manager)。 将 NSG 关联到子网时，规则适用于连接到该子网的所有资源。 也可通过将 NSG 关联到 VM 或 NIC 来进一步限制流量。

3.Azure Load Balancer

Azure 负载均衡器可提高应用程序的可用性和网络性能。 它是第 4 层（TCP、UDP）类型的负载均衡器，可在负载均衡集中定义的运行状况良好的服务实例之间分配传入流量。

Azure 负载均衡器使用基于哈希的分发算法。 默认情况下，它使用 5 元组哈希（包括源 IP、源端口、目标 IP、目标端口和协议类型）将流量映射到可用服务器。

4.Azure NAT

配置负载均衡器中的端口转发功能来实现NAT功能。

5.Azure VNET GW

要跨虚拟网络，需要配置点到站点虚拟专用网。

6.Azure VNET Peering

使用虚拟网络对等互连可以无缝连接两个 Azure 虚拟网络。 建立对等互连后，出于连接目的，两个虚拟网络会显示为一个。 对等虚拟网络中虚拟机之间的流量通过 Microsoft 主干基础结构路由，非常类似于只通过专用 IP 地址在同一虚拟网络中的虚拟机之间路由流量。

7.Azure NVA + UDR

可以在 Azure 中创建自定义或用户定义路由，以便替代 Azure 的默认系统路由，或者向子网的路由表添加其他路由。 可以在 Azure 中创建一个路由表，然后将该路由表关联到零个或零个以上的虚拟网络子网。 每个子网可以有一个与之关联的路由表，也可以没有。 如果创建一个路由表并将其关联到子网，则其中的路由会与 Azure 默认情况下添加到子网的默认路由组合在一起，或者将其替代。

8.Azure ExpressGW

专线连接。