第 4 周 - 学习总结

发布于: 9 小时前

1 复习上周课程

  1. 答疑、回顾上周作业并点评助教代码。

2 系统架构概述:互联网系统面临怎样的挑战?

  1. 20年前,系统架构采用微软、oracle、ibm、用友、金蝶等提供的系统架构方案。20年前是银行、零售巨头的架构解决方案。

  2. 最近20年来厂商和解决方案发生很大变化。因为应用方式变化(面向互联网的应用)、另外google、百度、阿里提供了更适合互联网应用的架构解决方案、互联网系统和以前的系统面对的问题不同,解决方案不同。

  3. 高并发(用户越来越多、访问越多、处理的和存储的越多、对系统资源消耗带来更大挑战cpu/内存/硬盘等)、大流量。

  4. 互联网分布式系统的高并发、高性能、高可用其实不是并列的。

  5. 高可用:系统7*24小时不间断服务。程序升级、机器不可用(比如内存硬盘故障)、网络不可用、应用服务不可用,但是系统还是要可用的。

  6. 用户分布广泛、网络情况复杂、用户终端千差万别。

  7. 安全环境恶劣。传统的内部系统,系统应用环境相对安全。

  8. 需求快速变更、发布频繁。

  9. 渐进式发展。无法一开始规划好全部的功能和非功能需求。所有大型互联网都是从小网站渐进式发展过来的的。

3 应对高并发挑战的两个技术方向

  1. 垂直伸缩,小型机--中型机--大型机,单个计算机的能力越来越强,可以升级服务器里的硬件,也可以升级服务器。

  2. 水平伸缩,通过增加服务器提升计算能力的一种架构方法。google大概200多万台服务器,不同服务器有不同的角色,有不同的计算职责,构成一个完整的大系统。加入机器后,如何和其他机器构成一个完整的大系统,承担何种角色。

  3. 初始阶段水平伸缩成本更高,有些时候垂直伸缩依然是一个可以考虑的方案。

4 互联网架构演化

  1. 架构演化的几个阶段:

5 互联网架构模式

  1. 前几周看的程序级别的设计模式

  2. 分层是企业应用系统中最常见的一种架构模式。网关层、微服务层(还可以细分业务服务、共用服务)、基础设施(缓存等)

  3. 分割,横向分层,纵向分割。横向分层4层,纵向分割为7个业务,4*7=28个模块。

  4. 分布式,各模块独立部署。

  5. 集群,几种访问的模块,需要独立部署的服务器集群化,通过负载均衡设备共同对外提供服务。

  6. 缓存、异步、冗余、安全

6 互联网系统架构核心要素:如何衡量一个系统的架构设计

  1. 一个系统有两个架构:功能性架构和非功能性架构。架构首先要满足功能性架构,但是每个系统的功能性架构都不太相同。所有的系统都应该满足一些非功能性的架构目标(非功能性架构5个方面:高性能、高可用、可伸缩、可扩展、安全)。

7 互联网架构技术一览

  1. 前端架构:架构师不一定清楚app如何做,但是需要知道前端架构如何设计,比如dns、cdn、动静分离、图片服务、反向代理、浏览器及http优化技术

  2. 网关及应用层架构:网关架构、负载均衡、动态页面静态化、业务拆分

  3. 服务层架构:微服务架构、分布式消息队列、分布式缓存、分布式一致性(锁)服务

  4. 存储层架构:分布式文件、分布式关系数据库、NoSQL数据库

  5. 后台架构:大数据平台、搜素引擎、推荐引擎、数据仓库(基本都是与数据相关)(很多都是离线批量计算得到的,不是实时请求计算)

  6. 运维与‘安全:数据采集与展示、数据监控与报警、攻击与防护、数据加密与解密。

8 案例

维基百科架构案例:维基百科全球第六大日访问量的网站,仅次于百度。非盈利、考捐款、小团队(10几个人)、服务器也很一般、三个数据中心。

  • lvs:负载均衡服务器。两个lvs,一个针对squid,一个针对应用服务器。

  • Squid:反向代理缓存服务器(缓存词条页面)

  • GeoDNS:根据用户的ip,判断用户所处地区,就近分发请求到就近的数据中心的lvs。

  • Image Server:图片服务器、为图片产生一个url地址,记录到数据库中

  • Distributed Object Cache:分布式对象缓存,先检查Memcached是否有这个词条,有则直接从缓存返回(缓存主要加速读数据,因为大多数请求都是读请求,避免数据库的压力)。

  • Invalidation notification:通知缓存失效(词条大部分是读操作,如果词条页面被编辑了,该词条被删除。缓存数据删除的两种手段:过期失效删除(如memcached)、失效通知删除(通知内容不包括新内容,缓存不更新的)。

淘宝早期技术演化:

  1. 2003年2000美金买来的php网站进行汉化。当年的c2c的核心交易方式是拍卖模式。

宅米技术架构2.0

  • 解决图片加载慢,用CDN服务,选择了云服务商的分布式文件系统(用来上传图片),就带了CDN服务,主要用的就是CDN服务。

  • 下单使用数据库,读操作(读商品信息)从Redis获取,读操作的图片文件使用分布式文件系统和CDN服务。

  • 数据库主从复制,读写分离购买的阿里云的mysql服务。

  • 大数据平台:对数据分析,对市场团队进行分析

宅米技术架构3.0

  • 微服务,复用,分布式服务集群

  • 订单数量众多,订单已经关闭了,存储在数据库中意义何在。订单关闭超过一个月,存储在MongoDB,一个月内在MySQL,一个月以上的数据在MongoDB。也可以时间更少的数据存在MySQL。每天夜里跑一个批处理,将一个月前的数据存到MongoDB,从主数据库中删除数据。

  • 做运营、对销售团队进行分析、对竞争对手分析、对特定商品的销售分析、对卖家进什么货指导。

技术部组织架构

  • 技术部:后端组、Web组、App组。产品需要和三个组沟通,开发效率,沟通效率低

  • 技术部按技术线分组:买家组、卖家组、后台组

  • 技术部:产品研发组(买家族、卖家组、后台组、测试组)、架构运维组(架构组、运维组)、数据平台组(数据平台组、数据分析组)、项目管理组(协调需求涉及各个组的开发、制定开发计划)

用户头像

大海

关注

还未添加个人签名 2018.07.14 加入

还未添加个人简介

评论

发布
暂无评论
第 4 周 - 学习总结