互联网架构模板

互联网的标准技术架构如下图所示，这张图基本涵盖了互联网技术公司的大部分技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范围。

1.存储层

1.1 SQL层

1.2 NOSQL层

1.3 小文件存储

    开源的，HBase，Hadoop，Hypertable，FastDFS等都可以作为小文件存储的底层平台。如果使用了阿里云，有存储系统OSS。

1.4 大文件存储

    互联网行业的大文件主要分为两类：一类是业务上的大数据，例如Youtube的视频、电影网站的电影；另一类是海量的日志数据，例如各种访问日志，操作日志，用户轨迹日志等。关于大数据的开源方案现在已经非常成熟了，例如Hadoop，Hbase，Storm，HIve等。

 

2.开发层

2.1 开发框架

    指定一个大的技术方向，然后使用统一的开发框架，如Java 相关的开发框架 SSH、SpringMVC、Play，Ruby 的 Ruby on Rails，PHP 的 ThinkPHP，Python 的 Django 等

    使用统一的开发框架能够大大提升组织和团队的开发效率

    框架选择原则：优选成熟的框架，避免盲目追逐新技术

2.2 Web服务器

    web服务器挑选流行的开源服务器，有能力的可以结合自己的业务做二次开发

    选择服务器主要和开发语言相关，Java 的有 Tomcat、JBoss、Resin 等，PHP/Python 的用 Nginx，或者直接选择Apache

    性能问题不是最高优先级的，等到业务发展到web服务器撑不住了再考虑

2.3 容器

    容器以Docker为代表，主要解决虚拟机启动慢、占资源多的问题

    Docker容器技术虽然没有跨平台，但启动快，几乎不占用资源

    Docker 可以随时启动和停止的特点，可以支持自动化运维、智能化运维

    设计模式将会偏向“微服务”方向发展，因为启动一个新的容器实例代价非常低

 

3.服务层技术

    服务层的主要目标就是为了降低系统间相互关联的复杂度。

3.1 配置中心

    配置中心就是集中管理各个系统的配置    

    配置中心的好处1：集中配置多个系统，操作效率高

    好处2：配置在一个集中的地方，检查方便，协作效率高

    好处3：配置中心可以实现程序化规则检查，避免常见错误    

    好处4：配置中心等于备份了系统的配置，可以实现快速搭建环境和恢复业务

3.2 服务中心

    服务中心就是为了解决跨系统依赖的“配置”和“调度”问题

    服务中心的实现一般有两种方式：服务名字系统和服务总线系统

    服务名字系统（Service Name System），是为了将 Service 名称解析为“host + port + 接口名称”，发起请求的还是请求方    

    服务总线系统（Service Bus System），由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了

    服务总线系统与服务名字系统对比

3.3 消息队列

    消息队列就是为了实现跨系统异步通知的中间件系统，既可以“一对一”通知，也可以“一对多”广播

    引入消息队列系统后，系统整体结构会变得简洁和清晰

    消息生产和消息的消费解耦，实现更简单

    增加新的信息消费者，消息生产者完全不需要改动，扩展更方便

    消息队列系统可以做高可用、高性能，避免各子系统重复做

    业务子系统专注于业务即可，实现更加简单

    消息队列比较成熟的开源实现方案：RocketMQ、Kafka、ActiveMQ 等

 

4.网络层

4.1 负载均衡

4.1.1 DNS

    最简单最常见的负载均衡方式，一般实现地理级别的均衡

    一般不会使用 DNS 做机器级别的负载均衡，因为太耗费 IP 资源

    DNS 负载均衡的优点是通用（全球通用）、成本低（申请域名，注册 DNS 即可）

    缺点是DNS 缓存的时间比较长，即使将某台业务机器从 DNS 服务器上删除，由于缓存的原因，还是有很多用户会继续访问已经被删除的机器

    另外DNS 不够灵活。DNS 不能感知后端服务器的状态，只能根据配置策略进行负载均衡，无法做到更加灵活的负载均衡策略

    对于时延和故障敏感的业务，可以尝试实现HTTP-DNS，即使用 HTTP 协议实现一个私有的 DNS 系统。HTTP-DNS 主要应用在通过 App 提供服务的业务

    HTTP-DNS的优点是灵活、可控、及时，但缺点是开发成本高、对APP有侵入性

4.1.2 Nginx、LVS、F5

    Nginx、LVS、F5 用于同一地点内机器级别的负载均衡

    Nginx 是软件的 7 层负载均衡，LVS 是内核的 4 层负载均衡，F5 是硬件的 4 层负载均衡

    软件和硬件的区别就在于性能，硬件远远高于软件，F5>LVS>Nginx

    4 层和 7 层的区别就在于协议和灵活性。Nginx 支持 HTTP、E-mail 协议，而 LVS 和 F5 是 4 层负载均衡，和协议无关

4.2 CDN

    CDN 是为了解决用户网络访问时的“最后一公里”效应，即将内容缓存在离用户最近的地方，用户访问的是缓存的内容

    CND目前包括很多内容，形成了很庞大的体系：分布式存储、全局负载均衡、网络重定向、流量控制等都属于 CDN 的范畴，尤其是在视频、直播等领域应用非常多

    CDN 作为网络的基础服务，独立搭建的成本巨大，不需要自行设计和搭建 CDN 系统，直接从 CDN 服务商购买 CDN 服务即可

    常见CDN服务商：网宿、蓝汛、阿里云、腾讯云

4.3 多机房

    单机房在全局来说，就是网络单点，在发生较大故障或灾害时无法保证业务高可用

    常见多机房设计策略有3种，同城多机房、跨城多机房、跨国多机房

    同城多机房对业务影响小，但投入较大，而且在极端情况下依然有风险

    跨城多机房因为距离远存在网络时延，所以在业务上需要妥协，不能保证数据的实时强一致性，只是保证最终一致性

4.4 多中心

    多中心必须以多机房为前提，是比多机房更复杂更难的设计策略

    多机房的主要目标是灾备，在机房故障时，可以比较快地将业务切换对另外一个机房，切换允许一定时间的中断，且业务可能有损失

    多中心的要求是每个中心都同时对外提供服务，且业务能够自动在多中心之间切换，故障后叶不需人工参与或很少人工参与就能自动恢复

    多中心设计的关键就在于“数据一致性”和“数据事务性”如何保证，这两个难点都和业务紧密相关，需要基于业务的特性进行详细的分析和设计

    因为多中心设计的复杂性，部分业务不能实现多中心，如银行、支付宝这类系统就没有完全实现多中心

 

5.用户层

5.1 用户管理

    用户管理的第一个目标：单点登录（SSO），又叫统一登录。

    单点登录的技术实现手段较多，例如 cookie、JSONP、token 等，目前最成熟的开源单点登录方案当属 CAS

    用户管理的第二个目标：授权登录。现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了事实上的标准

    业务做大成为了平台后，开放成为了促进业务进一步发展的手段，需要允许第三方应用接入，所以需要授权登录

5.2 消息推送

    消息推送根据不同的途径，分为短信、邮件、站内信、App 推送，短信需要依赖运营商的短信接口，邮件需要依赖邮件服务商的邮件接口，站内信是系统提供的消息通知功能

    App 目前主要分为 iOS 和 Android 推送，iOS 系统比较规范和封闭，基本上只能使用苹果的 APNS

    Android推送比较特殊， 在国外用 GCM 和 APNS ；在国内Android 的消息推送比较杂乱，有实力的大厂都会自己实现一套消息推送机制，例如阿里云移动推送、腾讯信鸽推送、百度云推送；也有第三方公司提    供商业推送服务，例如友盟推送、极光推送等

    消息推送主要包含 3 个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，分别对应的技术难点是海量设备和用户管理、连接保活、消息管理    

5.3 存储云、图片云

    互联网场景下用户需要上传多种类型的文件数据，包括图片、视频等，特点是数据量大、文件体积小、访问有时效性

    存储云和图片云通常的实现都是“CDN + 小文件存储”，现在有了“云”之后，直接买云服务可能是最快也是最经济的方式

    图片涉及的业务包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务

 

6.业务层技术

    业务复杂度越来越高。也就是说，业务层面对的主要技术挑战是“复杂度”

    复杂度越来越高的一个主要原因就是系统越来越庞大，业务越来越多。唯一方法就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里

    随着子系统越来越多，会凸显一个新的复杂度问题：子系统数量太多，已经没有人能够说清楚业务的调用流程了，出了问题排查也会特别复杂

    解决方法是“合”，但不是合并为一个统一系统，而是按照“高内聚低耦合”原则将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现

 

7.运维平台

    运维平台核心的职责分为四大块：配置、部署、监控、应急，每个职责对应系统生命周期的一个阶段，如下图所示。

    配置：主要负责资源的管理。例如，机器管理、IP 地址管理、虚拟机管理等。

    部署：主要负责将系统发布到线上。例如，包管理、灰度发布管理、回滚等。

    监控：主要负责收集系统上线后的相关数据并进行监控，以便及时发现问题。

    应急：主要负责系统出故障后的处理。例如，停止程序、下线故障机器、切换IP等。

    运维平台的核心要素是“四化”：标准化、平台化、自动化、可视化。

7.1 标准化

    需要定制运维标准，规范配置管理、部署流程、监控指标、应急能力等，各系统按照运维标准来实现，避免不同的系统不同的处理方式。标准化是运维平台的基础，没有标准化就没有运维平台。

    如果某个系统就是无法改造自己来满足运维标准，那该怎么办呢？常见的做法是不改造系统，由中间方来完成规范适配。例如，某个系统对外提供了RESTFUL接口的方式来查询当前的性能指标，而运维标准是通过日志定时上报，那么就可以写一个定时程序访问RESTFUL接口获取性能指标，而运维标准是性能数据通过日志定时上报，那么就可以写一个定时程序访问RESTFUL接口获取性能数据，然后转换为日志，上报到运维平台。

7.2 平台化

    传统的手工运维方式需要投入大量人力，效率低，容易出错，因此需要在运维标准化的基础上，将运维的相关操作都集成到运维平台上，通过运维平台来完成运维工作。

    运维平台的好处有：

    可以将运维标准固话到平台。无需运维人员死记运维标准。

    运维平台提供简单方便的操作，相比之下人工操作低效且容易出错。

    运维平台是可复用的，一套运维平台可以支持几百上千个业务系统。

7.3 自动化

    传统手工运维效率低下的一个主要原因就是要执行大量重复操作，运维平台可以将这些重复操作固化下来，由系统自动完成。

    例如，一次手工部署需要登录机器、上传包、解压包、备份旧系统、覆盖旧系统、启动新系统，这个过程中需要执行大量重复或者类似的操作。有了运维平台后，平台需要提供自动化的能力。，完成上述操作，部署人员只需要在最开始单机“开始部署”按钮，系统部署完成后，通知部署人员即可。

7.4 可视化

    运维平台有非常多的数据，如果全部通过人工去查询数据再来判断，则效率很低。尤其是在故障应急时，时间就是生命，处理问题都是争分夺秒，能减少1分钟的时间就可挽回几十万元的损失，可视化的主要目的就    是为了提升数据查看效率。

    可视化的原理与汽车仪表盘类似，如果只是一连串的数字显示在屏幕上，相信大部分人一看到一连串的数字，第一感觉是眼花，而且很难讲数据与具体的情况联系起来。而有了仪表盘后，通过仪表盘的指针偏离    幅度以及指针指向的区域颜色，能够一目了然的看出当前的状态是低速、中速还是高速。

    可视化相比简单的数据罗列，具备下面优点：

    • 能够直观地看到数据相关属性，例如，汽车仪表盘中的数据最小值是0，最大是100，单位是MPH。

    • 能够将数据的含义展示出来，例如汽车仪表盘中不同速度的颜色指示。

    • 能够将关联数据整合一起展示，例如汽车仪表盘的速度和里程。

 

8.测试平台

    测试平台核心的职责当然是测试了，包括单元测试、集成测试、接口测试、性能测试等，都可以在测试平台来完成。

    测试平台的核心目的是提升测试效率，从而提升产品质量，其设计关键就是自动化。传统的测试方式是测试人员手工执行测试用例，测试效率低，重复的工作多，为了达到自动化的目标，测试平台的基本架构如下图所示：

8.1 用例管理

    测试自动化的主要手段就是通过脚本或者代码来进行测试，例如单元测试用例是代码、接口测试用例可以用python来写、可靠性测试用例可以用Shell来写。为了能够重复执行这些测试用例，测试平台需要将用例管理起来，管理的维度包括业务、系统、测试类型、用例代码。例如，网购业务的订单系统的接口测试用例。

8.2 资源管理

    测试用例要放到具体的运行环境中才能执行，运行环境包括硬件（服务器、手机、平板电脑等）、软件（操作系统、数据库、java虚拟机）、业务系统（被测试的系统）。

    除了性能测试、一般的自动化测试对性能要求不高，所以为了提升资源利用率，大部分的测试平台都会使用虚拟技术来充分利用硬件资源，如虚拟机、docker等技术。

8.3 任务管理

    任务管理的主要职责是将测试用例分配到具体的资源上执行，跟踪任务的执行情况。任务管理是测试平台设计的核心。它将测试平台的各个部分串联起来从而完成自动化测试。

8.4 数据管理

    测试任务执行完成后，需要记录各种相关数据（例如，执行时间，执行结果，用例执行期间的CPU，内存占用情况等等），这些数据具备下面这些作用：

    • 展现当前用例的执行情况

    • 作为历史数据，方便后续的测试与历史数据进行对比，从而发现明显的变化趋势。

    • 作为大数据的一部分，可以基于测试的任务数据进行一些数据挖掘。例如，某个业务一年执行了10000个用例测试，另外一个业务只执行了1000个用例测试，两个业务规模和复杂度差不多，为何差异这么大？

 

9.数据平台

    数据平台的核心职责包括三个方面：数据管理、数据分析和数据应用。每一部分又包含更多的细分领域，详细的数据平台架构如下图所示。

9.1 数据管理

    数据管理包括数据采集、数据存储、数据访问和数据安全四个核心职责，是数据平台的基础功能。

    • 数据采集：从业务系统搜集各类数据。例如，日志，用户行为，业务数据等，将这些数据传送到数据平台。

    • 数据存储：将从业务系统采集的数据存储到数据平台，用于后续数据分析。

    • 数据访问：负责对外提供各种协议用于读写数据。例如，SQL、Hive、key-value等读写协议。

    • 数据安全：通常情况下数据平台都是多个业务共享的，部分业务敏感数据需要加以保护，防止被其他业务读取甚至修改，因此需要设计数据安全策略来保护数据。

9.2 数据分析

    数据分析包括数据统计、数据挖掘、机器学艺、深度学习等几个细分领域。

    • 数据挖掘：数据挖掘这个概念本身含义可以很广，为了与机器学习和深度学习区分开，这里的数据挖掘主要是指传统的数据挖掘方式。例如，有经验的数据分析人员基于数据仓库构建一系列规则来对数据进行分析从而发现一些隐含的规律、现象、问题等，经典的数据挖掘案例就是沃尔玛的啤酒与尿布的关联关系的发现。

    • 机器学习、深度学习：机器学习和深度学习属于数据挖掘的一种具体实现方式，由于其实现方式与传统的数据挖掘方式差异较大，因此数据平台在实现机器学习和深度学习时，需要针对机器学习和深度学习独立进行设计。

9.3 数据应用

    • 数据应用很广泛，既包括在线业务，也包括离线业务。例如，推荐、广告等属于在线应用，报表、欺诈检测、异常检测等属于离线应用。

    • 数据应用能够发挥价值的前提是需要有“大数据”，只有当数据的规模达到一定程度，基于数据的分析、挖掘才能发现有价值的规律、现象、问题等。如果数据没有达到一定规模，通常情况下做好数据统计就可以了，尤其是一些初创企业，无需一开始就参考BAT来构建自己的数据平台。

 

10.管理平台

    管理平台的核心职责就是权限管理，无论是业务系统（例如，淘宝网）、中间件系统（例如消息队列RocketMQ），还是平台系统（例如，运维平台），都需要进行管理。如果每个系统都自己来实现权限管理，效率太低、重复工作很多，因此需要统一的管理平台来管理所有的系统的权限。

    权限管理主要分为两部分：身份认证、权限控制，其基本架构如下图所示。

10.1 身份认证

    确定当前的操作人员身份，防止非法人员进入系统。例如，不允许匿名用户进入系统。为了避免每个系统都自己来管理用户，通常情况下会使用企业账号来做统一认证和管理。

10.2 权限控制

    根据操作人员的身份确定操作权限，防止未经授权的人员进行操作。例如不允许研发人员进入财务系统查看别人的工资。

 

 

最后

以上就是现实樱桃为你收集整理的互联网架构模板的全部内容，希望文章能够帮你解决互联网架构模板所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。