技术角 | 架构学习书摘总结（五）架构实战（中）

2020-05-13 09:41:03 浏览数 (1)

最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。

本文是该书第五部分中的第十八章，主要介绍互联网架构模板等架构实际案例内容。

目录

▪第十八章 互联网架构模板

第十八章 互联网架构模板

上图基本涵盖互联网技术公司的大部分技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。

  1. 存储层技术
    1. SQL SQL即我们通常所说的关系型数据(库)。随着互联网业务的发展，性能要求越来越高，必然面对一个问题：将数据拆分到多个数据库实例才能满足业务的性能需求（其实Oracle也一样，只是时间早晚的问题）。数据库拆分满足了性能的要求，但带来了复杂度的问题：数据如何拆分、数据如何组合。所以互联网公司流行的做法是业务发展到一定阶段后，就会将这部分功能独立成中间件，例如淘宝的TDDL。再后期会导致新的复杂度问题：数据库资源使用率不高，比较浪费以及各SQL集群分开维护，投入的维护成本越来越高。因此，实力雄厚的大公司此时一般都会在SQL集群上构建SQL存储平台，以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务。例如，淘宝的UMP(Unified MySQL Platform)系统。
    2. NoSQL NoSQL不是No SQL，而是Not Only SQL，即NoSQL是SQL的补充。首先NoSQL在数据结构上与传统的SQL的不同，例如典型的Memcache的key-value结构、Redis的复杂数据结构、MongoDB的文档数据结构；其次，NoSQL无一例外地都会将性能作为自己的一大卖点。 NoSQL的这两个特点很好地弥补了关系数据库的不足，因此在互联网行业NoSQL的应用基本上是基础要求。 由于NoSQL方案一般自己本身就提供集群功能，因此NoSQL在刚才是应用时很方便，不像SQL分库分表那么复杂。而NoSQL发展到一定规模后，通常都会在NoSQL集群的基础之上再实现统一存储平台。统一存储平台主要实现资源动态按需动态分配、资源自动化管理、故障自动化处理等几个功能。当然要发展到这个阶段，一般也是大公司才会这么做，简单来说就是如果只有几十台NoSQL服务器，那么做存储平台的收益不大；但如果有几千台NoSQL服务器，那么NoSQL存储平台就能够产生很大的收益。
    3. 小文件存储 除了关系型的业务数据，互联网行业还有很多用于展示的数据。这些数据具有数据量小一般在1M以下、数据量巨大、访问量巨大的典型特点。Facebook 2013年就达到每天上传3.5亿张照片，访问量超过10亿的规模。和SQL和NoSQL不同的是，小文件存储不一定需要公司或者业务规模很大，基本上认为业务在起步阶段就可以考虑做小文件统一存储。得益于开源与大数据，开源方案基础上封装一个小文件存储平台不太难。例如HBASE、Hadoop、Hypertable、FastDFS等都可以作为小文件存储的底层平台，只需要在这些开源方案上再包装一下基本上就可以用了。
    4. 大文件存储 互联网行业的大文件主要分为两类：一类是业务上的大数据，例如YouTube的视频、电影；一类是海量的日志数据，例如各种访问日志、操作日志、用户轨迹日志等。大文件没有小文件那么多，但每个文件都很大。这块开源方案也很成熟了，所以大数据存储和处理可以选择Hadoop、HBASE、Storm、Hive等。
  2. 开发层技术
    1. 开发框架 互联网公司都会指定一个大的技术方向，然后使用统一的开发框架。例如，Java相关的开发框架SSH、SpringMVC、SpringCloud、Play，Ruby的Ruby on Rails，PHP的ThinkPHP，Python的Django等等。使用统一的开发框架能够解决上面提到的各种问题，大大提升组织和团队的开发效率。 对于框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术。首先，成熟的框架资料文档齐备；其次，成熟的框架受众更广，招聘时更容易招到合适的人才；最后，成熟的框架更加稳定，不会出现大的变动，适合长期发展。
    2. Web服务器 开发框架只是负责完成业务功能的开发，真正能够运行起来，给用户提供服务，还需要服务器配合。选择一个服务器主要和开发语言相关，例如Java有Tomcat、JBoss、Resin等，PHP/Python的用Nginx，当然最保险的就是用Apache了，什么语言都支持。有人要担心Apache性能之类的问题，其实不用过早担心这个，等到业务真的发展到Apache撑不住的时候再考虑切换也不迟，那时候你有的是钱，有的是人，有的是时间。
    3. 容器 传统的虚拟化技术是虚拟机，解决了跨平台的问题，但由于虚拟机太庞大，启动慢，运行时太占资源，在互联网行业并没有大规模地应用；而Docker的容器技术，虽然没有跨平台，但启动快，几乎不占资源，推出后立刻就火起来了。不要以为Docker只是一个虚拟化或容器技术，它将在很大程度上改变目前的技术形势：
      1. 运维方式会发生革命性的变化：Docker启动快，几乎不占资源，随时启动停止，基于Docker打造自动化运维、智能化运维将成为主流方式。
      2. 设计模式会发生本质上的变化：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微服务”的方向发展。

    例如，一个传统的网站包括登录注册、页面访问、搜索等功能，没有用容器的情况下，除非有特别大的访问量，否则这些功能开始时都是集成在一个系统里面的；有了容器技术以后，一开始就可以将这些功能按照服务的方式设计，避免后续访问量增大时又要重构系统。

  3. 服务层技术 服务层的主要目标是为了降低系统间相互关联的复杂度。
    1. 配置中心 配置中心就是集中管理各个系统的配置。将配置中心做成通用的系统有如下好处：
      1. 集中配置多个系统，操作效率高。
      2. 所有配置都在一个集中的地方，检查方便，协作效率高。
      3. 配置中心可以实现程序化的规则检查，避免常见的错误。
      4. 配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务。

    配置中心通过“系统标示 host port”来标示唯一一个系统运行实例是常见的设计方法。

    1. 服务中心 服务中心未来解决跨系统依赖的配置和调度问题。其实现一般来说有两种方式：服务名字系统和服务总线系统。 服务名字系统（Service Name System），类似于DNS，其是为了将Service名称解析为“host port 接口名称”，但是和DNS一样，真正发起请求的还是请求方。 服务总线系统（Service Bus System），类似于计算机总线，其为了直接由总线系统完成调用，服务请求方不需要直接和服务提供方交互。 两者简单对比如下： 服务总线系统服务名字系统复杂度设计更加复杂，要同时完成配置和调度功能，且本身高性能和高可用的设计也更加复杂。设计简单，基本类似一个服务配置中心，如果要做调度，需要独立的SDK包。可用性可用性的关键，它故障后所有业务间的访问都调用，影响较大，但因为服务总线主要做调度，可以部署两套或多套并行系统。仅仅保存配置，调用还是由服务请求方发起，可用性要求没那么高，即使故障，各系统也可以使用本地缓存配置继续完成调用。灵活性控制所有的调度和配置，可以做得非常灵活。仅仅有配置，即使提供独立的SDK支持调度，灵活性也要差一点，毕竟SDK只能获取静态的配置信息。实时性系统完成实际的调度，可以做到非常实时，例如某个服务及机器故障后立刻剔除故障节点。提供调度的SDK包，也需要定时更新配置，不能每次请求都去获取一下最新的配置，实时性一般，这个问题和DNS类似。可维护性服务总线系统的修改和升级只需要自己完成即可。修改和升级大部分情况下要修改SDK包（例如，调度算法变更），修改SDK包要求所有系统应用新SDK包才能生效。多语言支持服务总线系统支持通用的HTTP和TCP协议，和语言无关。服务名字系统提供的SDK包需要适配多个语言，这个工作量也不小。
    2. 消息队列 消息队列系统基本功能的实现比较简单，但要做到高性能、高可用、消息时序性、消息事务性则比较难。
  4. 网络层技术
    1. 负载均衡 负载均衡就是将请求均衡的分配到多个系统上。其实现方式很多，可大可小，可以软件实现，也可以硬件实现。 DNS是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。DNS负载均衡的优点是通用、成本低，但缺点也明显：DNS缓存时间比较长；DNS不能感知后端服务器的状态，只能根据配置策略进行负载均衡，无法做到更加灵活的负载均衡策略。所以对于时延和故障敏感的业务，有一些公司自己实现了HTTP-DNS的功能，即使用HTTP协议实现一个私有的DNS系统，这样的方案与通用DNS优缺点正好相反。 Nginx&LVS&F5用于同一地点内及其级别的负载均衡，其中Nginx是软件的7层负载均衡，LVS是内核的4层负载均衡，F5是硬件做4层负载均衡。 软件和硬件的区别就在于性能，硬件远远高于软件，Nginx的性能是万级，一般的Linux服务器上装个Nginx大概能到5万/秒；LVS的性能是十万级，没有具体测试过，据说可以达到80万/秒；F5性能是百万级，从200万/秒-800万/秒都有。 4层和7层的区别在于协议和灵活性。Nginx支持HTTP、E-mail等协议，而LVS和F5是4层负载均衡，和协议无关，几乎所有应用都可以做，例如聊天、数据库等。
    2. CDN CDN是为了解决用户忘了访问时的”最后一公里“效应，即将内容缓存在离用户最近的地方，用户访问的是缓存的内容，而不是站点实时内容。CDN经过多年的发展，已经变成了一个很庞大的体系：分布式存储、全局负载均衡、网络重定向、流量控制等都属于CDN的范畴。
    3. 多机房 多机房设计最核心的因素就是如何处理时延带来的影响。常见策略有： 同城多机房：可搭建私有高速网络，基本做到与同机房一样的效果。对业务影响较小，但投入较大，而且遇到地震水灾等严重自然灾害也是有很大风险。 跨城多机房：机房间通过网络进行数据复制，但由于跨城网络时延问题业务上需要做一定的妥协和兼容，不需要数据的实时强一致性，保证最终一致性即可。这种方式实现简单，但和业务有很强的相关性，微博可以这样做，支付宝就不能这样做。 跨国多机房：同跨城多机房，只是地理分布更远、时延更大。所以一般仅用于备份和服务本国用户。
    4. 多中心 多中心要求每个中心都同时对外提供服务，且业务能够自动在多中心之间切换，故障后不需要人工干预或很少干预就能自动恢复。 多中心设计的关键就在于”数据一致性“和”数据事务性“如何保证，但这两个难点都和业务紧密相关，不存在通用的解决方案，需要基于业务的特性进行详细的分析和设计。正因为多中心设计的复杂性，不一定所有业务都能实现多中心，目前国内的银行、支付宝这类系统就没有完全实现多中心。不然也不会出现挖掘机一铲子下去，支付宝中断4小时的故障。
  5. 用户层技术
    1. 用户管理 第一个目标：SSO，单点登录，又叫统一登录。单点登录的技术实现手段较多，例如cookie、token等，最有名的开源方案为CAS。 第二个目标：授权登录。现在最流行的授权登录就是OAuth 2.0协议，基本上已经成为事实上的标准，如果要做开放平台，则最好用这个协议，私有协议漏洞多，第三方介入也麻烦。 用户管理面临的主要问题是用户数巨大，一般至少千万级，但实现起来并不难，主要是因为不同用户之间没有关联。
    2. 消息推送 消息推送根据不同的途径，分为短信、邮件、站内信、App推送。App目前主要分为iOS和Android推送，iOS系统比较规范和封闭，基本上只能使用苹果的APNS了；但Android在国外用GCM和APNS差别不大，但在国内GCM不能用，另外各个厂商都有自己定制的Android，消息推送实现也不完全一样。通常情况下，对于中小公司，如果不涉及敏感数据，则Android系统上推荐使用第三方推送服务，因为这些第三方是专业做推送服务的，消息到达率是有一定保证的。 如果涉及敏感数据，则需要自己实现消息推送，这时就有一定的技术挑战了。消息推送主要包含3个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，技术上面临的主要挑战有：海量设备和用户管理、连接保活、消息管理。
    3. 存储云与图片云 通常的实现都是”CDN 小文件存储“。由于图片业务的复杂性，普通的文件基本上提供存储和访问功能就够了，但图片涉及的业务可能包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务。
  6. 业务层技术 业务层面对的主要技术挑战是复杂性，而不管什么业务难题，用上”拆“问题一般都迎刃而解。究其原因，复杂性的一个主要原因就是系统越来越庞大，业务越来越多，降低复杂性最好的方式就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或子系统里面去。 而子系统数量过多，则需要“合”。按照“高内聚，低耦合”的原则，将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现，类似于设计模式中的Facade模式。
  7. 平台技术
    1. 运维平台 运维平台核心的职责分为四大块：配置（资源管理：机器、IP、虚拟机）、部署（将系统发布到线上：包、灰度发布、回滚）、监控（收集系统上线运行后的相关数据并进行监控以便及时发现问题）、应急（系统出故障后的处理：停止程序、下线故障机器、切换IP）。 运维平台的核心设计要素：标准化、平台化、自动化、可视化。 标准化：需要制定运维标准，规范配置管理、部署流程、监控指标、应急能力等，各系统按照运维标准来实现，避免不同的系统不同的处理方式。标准化是运维平台的基础，没有标准化就没有运维平台。 平台化：在运维标准化的基础上，将运维的相关操作都集成到运维平台中，通过运维平台来完成运维工作。通过平台可将运维标准固化到平台中，且可以同简单方便的操作，可以复用支撑几百上千个业务系统。 自动化：将重复操作固化，由系统自动完成。类似还有监控。 可视化：提升数据查看效率，原理与汽车仪表盘类似。可直观地看到数据的相关属性，能够将数据的含义展示出来，能够将关联数据整合一起展示。
    2. 测试平台 核心职责是测试，包括单元测试、集成测试、接口测试、性能测试等。测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化。为达到自动化，测试平台包括用例管理、资源管理、任务管理、数据管理等。
    3. 数据平台 核心职责包括数据管理、数据分析和数据应用。其中数据管理包括数据采集、数据存储、数据访问和数据安全四个核心职责，是数据平台的基础。数据分析包括数据统计、数据挖掘、机器学习、深度学习等几个细分领域。数据应用就广泛了，既包括在线业务，也包括利息按业务。例如推荐、广告等属于在线应用，报表、欺诈简称、异常检测等属于离线应用。
    4. 管理平台 核心职责是权限管理，无论业务系统（例如淘宝网）、中间件系统（例如消息队列Kafka），还是平台系统（例如运维平台）都需要进行管理。权限管理主要分为两部分：身份认证、权限控制。
运维 负载均衡 负载均衡缓存 nosql

0 人点赞