互联网架构模板

互联网的标准技术架构如下图所示这张图基本上涵盖了互联网技术公司的大部分技术点不同的公司只是在具体的技术实现上稍有差异但不会跳出这个框架的范畴。互联网架构模板“存储层”技术SQLSQL 即我们通常所说的关系数据。前几年 NoSQL 火了一阵子很多人都理解为 NoSQL 是完全抛弃关系数据全部采用非关系型数据。但经过几年的试验后大家发现关系数据不可能完全被抛弃NoSQL 不是 No SQL而是 Not Only SQL即 NoSQL 是 SQL 的补充。所以互联网行业也必须依赖关系数据考虑到 Oracle 太贵还需要专人维护一般情况下互联网行业都是用 MySQL、PostgreSQL 这类开源数据库。这类数据库的特点是开源免费拿来就用但缺点是性能相比商业数据库要差一些。。随着互联网业务的发展性能要求越来越高必然要面对一个问题将数据拆分到多个数据库实例才能满足业务的性能需求(其实 Oracle 也一样只是时间早晚的问题)。数据库拆分满足了性能的要求但带来了复杂度的问题数据如何拆分、数据如何组合如果每个业务都去实现一遍重复造轮子将导致投入浪费、效率降低业务开发想快都快不起来。 所以互联网公司流行的做法是业务发展到一定阶段后就会将这部分功能独立成中间件例如百度的 DBProxy、淘宝的 TDDL。不过这部分的技术要求很高将分库分表做到自动化和平台化不是一件容易的事情所以一般是规模很大的公司才会自己做。中小公司建议使用开源方案例如 MySQL 官方推荐的 MySQL Router、360 开源的数据库中间件 Atlas。实力雄厚的大公司此时一般都会在 SQL 集群上构建 SQL 存储平台以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务例如淘宝的 UMP(Unified MySQL Platform)系统。NoSQL首先 NoSQL 在数据结构上与传统的 SQL 的不同例如典型的 Memcache 的 key-value 结构、Redis 的复杂数据结构、MongoDB 的文档数据结构其次NoSQL 无一例外地都会将性能作为自己的一大卖点。NoSQL 的这两个特点很好地弥补了关系数据库的不足因此在互联网行业 NoSQL 的应用基本上是基础要求。由于 NoSQL 方案一般自己本身就提供集群的功能例如 Memcache 的一致性 Hash 集群、Redis 3.0 的集群因此 NoSQL 在刚开始应用时很方便不像 SQL 分库分表那么复杂。一般公司也不会在开始时就考虑将 NoSQL 包装成存储平台首先是存储平台通过集中管理能够大大提升运维效率其次是存储平台可以大大提升资源利用效率 2000 台机器如果利用率能提升 10%就可以减少 200 台机器一年几十万元就节省出来了。所以NoSQL 发展到一定规模后通常都会在 NoSQL 集群的基础之上再实现统一存储平台统一存储平台主要实现这几个功能资源动态按需动态分配例如同一台 Memcache 服务器可以根据内存利用率分配给多个业务使用。资源自动化管理例如新业务只需要申请多少 Memcache 缓存空间就可以了无需关注具体是哪些 Memcache 服务器在为自己提供服务。故障自动化处理例如某台 Memcache 服务器挂掉后有另外一台备份 Memcache 服务器能立刻接管缓存请求不会导致丢失很多缓存数据。小文件存储除了关系型的业务数据互联网行业还有很多用于展示的数据。由于互联网行业基本上每个业务都会有大量的小数据如果每个业务都自己去考虑如何设计海量存储和海量访问效率自然会低重复造轮子也会投入浪费所以自然而然就要将小文件存储做成统一的和业务无关的平台。和 SQL 和 NoSQL 不同的是小文件存储不一定需要公司或者业务规模很大基本上认为业务在起步阶段就可以考虑做小文件统一存储。得益于开源运动的发展和最近几年大数据的火爆在开源方案的基础上封装一个小文件存储平台并不是太难的事情。例如HBase、 Hadoop、Hypertable、FastDFS 等都可以作为小文件存储的底层平台只需要将这些开源方案再包装一下基本上就可以用了。典型的小文件存储有淘宝的 TFS、京东 JFS、Facebook 的 Haystack。淘宝 TFS 的架构大文件存储互联网行业的大文件主要分为两类一类是业务上的大数据例如 Youtube 的视频、电影网站的电影另一类是海量的日志数据例如各种访问日志、操作日志、用户轨迹日志等。对照 Google 的论文构建一套完整的大数据处理方案的难度和成本实在太高而且开源方案现在也很成熟了所以大数据存储和处理这块反而是最简单的因为你没有太多选择只能用这几个流行的开源方案例如Hadoop、HBase、Storm、Hive 等。实力雄厚一些的大公司会基于这些开源方案结合自己的业务特点封装成大数据平台例如淘宝的云梯系统、腾讯的 TDW 系统。Hadoop 的生态圈互联网架构模板“开发层”和“服务层”技术开发层技术1. 开发框架 互联网业务发展的一个特点复杂度越来越高。复杂度增加的典型现象就是系统越来越多不同的系统由不同的小组开发。不同的开发框架和技术则会带来很多问题典型的问题有技术人员之间没有共同的技术语言交流合作少。每类技术都需要投入大量的人力和资源并熟练精通。不同团队之间人员无法快速流动人力资源不能高效的利用。所以互联网公司都会指定一个大的技术方向然后使用统一的开发框架。例如Java 相关的开发框架 SSH、SpringMVC、PlayRuby 的 Ruby on RailsPHP 的 ThinkPHP Python 的 Django 等。使用统一的开发框架能够解决上面提到的各种问题大大提升组织和团队的开发效率。2.Web 服务器 开发框架只是负责完成业务功能的开发真正能够运行起来给用户提供服务还需要服务器配合。独立开发一个成熟的 Web 服务器成本非常高况且业界又有那么多成熟的开源 Web 服务器所以互联网行业基本上都是“拿来主义”挑选一个流行的开源服务器即可。选择一个服务器主要和开发语言相关例如Java 的有 Tomcat、JBoss、Resin 等 PHP/Python 的用 Nginx当然最保险的就是用 Apache 了什么语言都支持。3. 容器 容器是最近几年才开始火起来的其中以 Docker 为代表在 BAT 级别的公司已经有较多的应用。例如腾讯万台规模的 Docker 应用实践.传统的虚拟化技术是虚拟机解决了跨平台的问题但由于虚拟机太庞大启动又慢运行时太占资源在互联网行业并没有大规模应用而 Docker 的容器技术虽然没有跨平台但启动快几乎不占资源推出后立刻就火起来了预计 Docker 类的容器技术将是技术发展的主流方向。千万不要以为 Docker 只是一个虚拟化或者容器技术它将在很大程度上改变目前的技术形势运维方式会发生革命性的变化Docker 启动快几乎不占资源随时启动和停止基于 Docker 打造自动化运维、智能化运维将成为主流方式。设计模式会发生本质上的变化启动一个新的容器实例代价如此低将鼓励设计思路朝“微服务”的方向发展。服务层技术互联网业务的不断发展带来了复杂度的不断提升业务系统也越来越多系统间相互依赖程度加深。比如说为了完成 A 业务系统可能需要 B、C、D、E 等十几个其他系统进行合作。从数学的角度进行评估可以发现系统间的依赖是呈指数级增长的3 个系统相互关联的路径为 3 条6 个系统相互关联的路径为 15 条。服务层的主要目标其实就是为了降低系统间相互关联的复杂度。1. 配置中心 配置中心就是集中管理各个系统的配置。当系统数量不多的时候一般是各系统自己管理自己的配置但系统数量多了以后这样的处理方式会有问题某个功能上线时需要多个系统配合一起上线分散配置时配置检查、沟通协调需要耗费较多时间。处理线上问题时需要多个系统配合查询相关信息分散配置时操作效率很低沟通协调也需要耗费较多时间。各系统自己管理配置时一般是通过文本编辑的方式修改的没有自动的校验机制容易配置错误而且很难发现。实现配置中心主要就是为了解决上面这些问题将配置中心做成通用的系统的好处有集中配置多个系统操作效率高。所有配置都在一个集中的地方检查方便协作效率高。配置中心可以实现程序化的规则检查避免常见的错误。比如说检查最小值、最大值、是否 IP 地址、是否 URL 地址都可以用正则表达式完成。配置中心相当于备份了系统的配置当某些情况下需要搭建新的环境时能够快速搭建环境和恢复业务。下面是配置中心简单的设计其中通过“系统标识 host port”来标识唯一一个系统运行实例是常见的设计方法。2. 服务中心 当系统数量不多的时候系统间的调用一般都是直接通过配置文件记录在各系统内部的但当系统数量多了以后这种方式就存在问题了。比如说总共有 10 个系统依赖 A 系统的 X 接口A 系统实现了一个新接口 Y能够更好地提供原有 X 接口的功能如果要让已有的 10 个系统都切换到 Y 接口则这 10 个系统的几十上百台机器的配置都要修改然后重启可想而知这个效率是很低的。除此以外如果 A 系统总共有 20 台机器现在其中 5 台出故障了其他系统如果是通过域名访问 A 系统则域名缓存失效前还是可能访问到这 5 台故障机器的如果其他系统通过 IP 访问 A 系统那么 A 系统每次增加或者删除机器其他所有 10 个系统的几十上百台机器都要同步修改这样的协调工作量也是非常大的。服务中心就是为了解决上面提到的跨系统依赖的“配置”和“调度”问题。服务中心的实现一般来说有两种方式服务名字系统和服务总线系统。服务名字系统(Service Name System)看到这个翻译相信你会立刻联想到 DNS即 Domain Name System。没错两者的性质是基本类似的。DNS 的作用将域名解析为 IP 地址主要原因是我们记不住太多的数字 IP域名就容易记住。服务名字系统是为了将 Service 名称解析为“host port 接口名称”但是和 DNS 一样真正发起请求的还是请求方。基本的设计如下服务总线系统(Service Bus System)相比服务名字系统服务总线系统更进一步了由总线系统完成调用服务请求方都不需要直接和服务提供方交互了。基本的设计如下“服务名字系统”和“服务总线系统”简单对比如下表所示。3. 消息队列 互联网业务的一个特点是“快”这就要求很多业务处理采用异步的方式。传统的异步通知方式是由消息生产者直接调用消息消费者提供的接口进行通知的但当业务变得庞大子系统数量增多时这样做会导致系统间交互非常复杂和难以管理因为系统间互相依赖和调用整个系统的结构就像一张蜘蛛网如下图所示。消息队列就是为了实现这种跨系统异步通知的中间件系统。消息队列既可以“一对一”通知也可以“一对多”广播。以微博为例可以清晰地看到异步通知的实现和作用如下图所示。对比前面的蜘蛛网架构可以清晰地看出引入消息队列系统后的效果整体结构从网状结构变为线性结构结构清晰。消息生产和消息消费解耦实现简单。增加新的消息消费者消息生产者完全不需要任何改动扩展方便。消息队列系统可以做高可用、高性能避免各业务子系统各自独立做一套减轻工作量。业务子系统只需要聚焦业务即可实现简单。消息队列系统基本功能的实现比较简单但要做到高性能、高可用、消息时序性、消息事务性则比较难。业界已经有很多成熟的开源实现方案如果要求不高基本上拿来用即可例如RocketMQ、Kafka、ActiveMQ 等。但如果业务对消息的可靠性、时序、事务性要求较高时则要深入研究这些开源方案否则很容易踩坑。开源的用起来方便但要改就很麻烦了。由于其相对比较简单很多公司也会花费人力和时间重复造一个轮子这样也有好处因为可以根据自己的业务特点做快速的适配开发。互联网架构模板“网络层”技术负载均衡负载均衡就是将请求均衡地分配到多个系统上。使用负载均衡的原因也很简单每个系统的处理能力是有限的为了应对大容量的访问必须使用多个系统。1.DNS DNS 是最简单也是最常见的负载均衡方式一般用来实现地理级别的均衡。DNS 负载均衡的优点是通用(全球通用)、成本低(申请域名注册 DNS 即可)但缺点也比较明显主要体现在DNS 缓存的时间比较长即使将某台业务机器从 DNS 服务器上删除由于缓存的原因还是有很多用户会继续访问已经被删除的机器。DNS 不够灵活。DNS 不能感知后端服务器的状态只能根据配置策略进行负载均衡无法做到更加灵活的负载均衡策略。比如说某台机器的配置比其他机器要好很多理论上来说应该多分配一些请求给它但 DNS 无法做到这一点。所以对于时延和故障敏感的业务有实力的公司可能会尝试实现HTTP-DNS的功能即使用 HTTP 协议实现一个私有的 DNS 系统。HTTP-DNS 主要应用在通过 App 提供服务的业务上因为在 App 端可以实现灵活的服务器访问策略如果是 Web 业务实现起来就比较麻烦一些因为 URL 的解析是由浏览器来完成的只有 Javascript 的访问可以像 App 那样实现比较灵活的控制。HTTP-DNS 的优缺点有灵活HTTP-DNS 可以根据业务需求灵活的设置各种策略。可控HTTP-DNS 是自己开发的系统IP 更新、策略更新等无需依赖外部服务商。及时HTTP-DNS 不受传统 DNS 缓存的影响可以非常快地更新数据、隔离故障。开发成本高没有通用的解决方案需要自己开发。侵入性需要 App 基于 HTTP-DNS 进行改造。2.Nginx 、LVS 、F5 DNS 用于实现地理级别的负载均衡而 Nginx、LVS、F5 用于同一地点内机器级别的负载均衡。其中 Nginx 是软件的 7 层负载均衡LVS 是内核的 4 层负载均衡F5 是硬件的 4 层负载均衡。软件和硬件的区别就在于性能硬件远远高于软件Ngxin 的性能是万级一般的 Linux 服务器上装个 Nginx 大概能到 5 万 / 秒LVS 的性能是十万级没有具体测试过据说可达到 80 万 / 秒F5 性能是百万级从 200 万 / 秒到 800 万 / 秒都有。硬件虽然性能高但是单台硬件的成本也很高一台最便宜的 F5 都是几十万但是如果按照同等请求量级来计算成本的话实际上硬件负载均衡设备可能会更便宜例如假设每秒处理 100 万请求用一台 F5 就够了但用 Nginx可能要 20 台这样折算下来用 F5 的成本反而低。因此通常情况下如果性能要求不高可以用软件负载均衡如果性能要求很高推荐用硬件负载均衡。4 层和 7 层的区别就在于协议和灵活性。Nginx 支持 HTTP、E-mail 协议而 LVS 和 F5 是 4 层负载均衡和协议无关几乎所有应用都可以做例如聊天、数据库等。目前很多云服务商都已经提供了负载均衡的产品例如阿里云的 SLB、UCloud 的 ULB 等中小公司直接购买即可。CDNCDN 是为了解决用户网络访问时的“最后一公里”效应本质上是一种“以空间换时间”的加速策略即将内容缓存在离用户最近的地方用户访问的是缓存的内容而不是站点实时的内容。简单的 CDN 请求流程示意图CDN 经过多年的发展已经变成了一个很庞大的体系分布式存储、全局负载均衡、网络重定向、流量控制等都属于 CDN 的范畴尤其是在视频、直播等领域如果没有 CDN用户是不可能实现流畅观看内容的。幸运的是大部分程序员和架构师都不太需要深入理解 CDN 的细节因为 CDN 作为网络的基础服务独立搭建的成本巨大很少有公司自己设计和搭建 CDN 系统从 CDN 服务商购买 CDN 服务即可目前有专门的 CDN 服务商例如网宿和蓝汛也有云计算厂家提供 CDN 服务例如阿里云和腾讯云都提供 CDN 的服务。多机房从架构上来说单机房就是一个全局的网络单点在发生比较大的故障或者灾害时单机房难以保证业务的高可用。例如停电、机房网络中断、地震、水灾等都有可能导致一个机房完全瘫痪。多机房设计最核心的因素就是如何处理时延带来的影响常见的策略有1. 同城多机房 同一个城市多个机房距离不会太远可以投入重金搭建私有的高速网络基本上能够做到和同机房一样的效果。 这种方式对业务影响很小但投入较大如果不是大公司一般是承受不起的而且遇到极端的地震、水灾等自然灾害同城多机房也是有很大风险的。2. 跨城多机房 在不同的城市搭建多个机房机房间通过网络进行数据复制(例如MySQL 主备复制)但由于跨城网络时延的问题业务上需要做一定的妥协和兼容比如不需要数据的实时强一致性只是保证最终一致性。3. 跨国多机房 和跨城多机房类似只是地理上分布更远时延更大。由于时延太大和用户跨国访问实在太慢跨国多机房一般仅用于备份和服务本国用户。多中心多中心必须以多机房为前提但从设计的角度来看多中心相比多机房是本质上的飞越难度也高出一个等级。简单来说多机房的主要目标是灾备当机房故障时可以比较快速地将业务切换到另外一个机房这种切换操作允许一定时间的中断(例如10 分钟、1 个小时)而且业务也可能有损失(例如某些未同步的数据不能马上恢复或者要等几天才恢复甚至永远都不能恢复了)。因此相比多机房来说多中心的要求就高多了要求每个中心都同时对外提供服务且业务能够自动在多中心之间切换故障后不需人工干预或者很少的人工干预就能自动恢复。多中心设计的关键就在于“数据一致性”和“数据事务性”如何保证这两个难点都和业务紧密相关目前没有很成熟的且通用的解决方案需要基于业务的特性进行详细的分析和设计。以淘宝为例淘宝对外宣称自己是多中心的但是在实际设计过程中商品浏览的多中心方案、订单的多中心方案、支付的多中心方案都需要独立设计和实现。互联网架构模板“用户层”和“业务层”技术将从“用户层”和“业务层”的角度谈谈常见的应用场景和关键技术。用户层技术1. 用户管理 互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来因此用户管理是互联网业务必不可少的一部分。稍微大一点的互联网业务肯定会涉及多个子系统这些子系统不可能每个都管理这么庞大的用户由此引申出用户管理的第一个目标单点登录(SSO)又叫统一登录。单点登录的技术实现手段较多例如 cookie、JSONP、token 等目前最成熟的开源单点登录方案当属 CAS其架构如下除此之外当业务做大成为了平台后开放成为了促进业务进一步发展的手段需要允许第三方应用接入由此引申出用户管理的第二个目标授权登录。现在最流行的授权登录就是 OAuth 2.0 协议基本上已经成为了事实上的标准如果要做开放平台则最好用这个协议私有协议漏洞多第三方接入也麻烦。用户管理系统面临的主要问题是用户数巨大一般至少千万级QQ、微信、支付宝这种巨无霸应用都是亿级用户。不过也不要被这个数据给吓倒了用户管理虽然数据量巨大但实现起来并不难原因是什么呢 因为用户数据量虽然大但是不同用户之间没有太强的业务关联A 用户登录和 B 用户登录基本没有关系。因此虽然数据量巨大但我们用一个简单的负载均衡架构就能轻松应对。用户管理的基本架构如下2. 消息推送 消息推送根据不同的途径分为短信、邮件、站内信、App 推送。除了 App不同的途径基本上调用不同的 API 即可完成技术上没有什么难度。App 目前主要分为 iOS 和 Android 推送iOS 系统比较规范和封闭基本上只能使用苹果的 APNS但 Android 就不一样了在国外用 GCM 和 APNS 差别不大但是在国内情况就复杂多了首先是 GCM 不能用其次是各个手机厂商都有自己的定制的 Android消息推送实现也不完全一样。因此 Android 的消息推送就五花八门了大部分有实力的大厂都会自己实现一套消息推送机制例如阿里云移动推送、腾讯信鸽推送、百度云推送也有第三方公司提供商业推送服务例如友盟推送、极光推送等。通常情况下对于中小公司如果不涉及敏感数据Android 系统上推荐使用第三方推送服务因为毕竟是专业做推送服务的消息到达率是有一定保证的。如果涉及敏感数据需要自己实现消息推送这时就有一定的技术挑战了。消息推送主要包含 3 个功能设备管理(唯一标识、注册、注销)、连接管理和消息管理技术上面临的主要挑战有海量设备和用户管理 消息推送的设备数量众多存储和管理这些设备是比较复杂的同时为了针对不同用户进行不同的业务推广还需要收集用户的一些信息简单来说就是将用户和设备关联起来需要提取用户特征对用户进行分类或者打标签等。连接保活 要想推送消息必须有连接通道但是应用又不可能一直在前台运行大部分设备为了省电省流量等原因都会限制应用后台运行限制应用后台运行后连接通道可能就被中断了导致消息无法及时的送达。连接保活是整个消息推送设计中细节和黑科技最多的地方例如应用互相拉起、找手机厂商开白名单等。消息管理 实际业务运营过程中并不是每个消息都需要发送给每个用户而是可能根据用户的特征选择一些用户进行消息推送。由于用户特征变化很大各种排列组合都有可能将消息推送给哪些用户这部分的逻辑要设计得非常灵活才能支撑花样繁多的业务需求具体的设计方案可以采取规则引擎之类的微内核架构技术。3. 存储云、图片云 互联网业务场景中用户会上传多种类型的文件数据例如微信用户发朋友圈时上传图片微博用户发微博时上传图片、视频优酷用户上传视频淘宝卖家上传商品图片等为了满足用户的文件上传和存储需求需要对用户提供文件存储和访问功能这里就需要用到“存储层”技术时提到的“小文件存储”技术。业务层技术 互联网的业务千差万别不同的业务分解下来有不同的系统所以业务层没有办法提炼一些公共的系统或者组件。抛开业务上的差异各个互联网业务发展最终面临的问题都是类似的业务复杂度越来越高。也就是说业务层面对的主要技术挑战是“复杂度”。复杂度越来越高的一个主要原因就是系统越来越庞大业务越来越多。幸运的是面对业务层的技术挑战我们有一把“屠龙宝刀”不管什么业务难题用上“屠龙宝刀”问题都能迎刃而解。这把“屠龙宝刀”就是“拆”化整为零、分而治之将整体复杂性分散到多个子业务或者子系统里面去。互联网架构模板“平台”技术当业务规模比较小、系统复杂度不高时运维、测试、数据分析、管理等支撑功能主要由各系统或者团队独立完成。随着业务规模越来越大系统复杂度越来越高子系统数量越来越多如果继续采取各自为政的方式来实现这些支撑功能会发现重复工作非常多。运维平台 运维平台核心的职责分为四大块配置、部署、监控、应急每个职责对应系统生命周期的一个阶段如下图所示。配置主要负责资源的管理。例如机器管理、IP 地址管理、虚拟机管理等。部署主要负责将系统发布到线上。例如包管理、灰度发布管理、回滚等。监控主要负责收集系统上线运行后的相关数据并进行监控以便及时发现问题。应急主要负责系统出故障后的处理。例如停止程序、下线故障机器、切换 IP 等。运维平台的核心设计要素是“四化”标准化、平台化、自动化、可视化。1. 标准化 需要制定运维标准规范配置管理、部署流程、监控指标、应急能力等各系统按照运维标准来实现避免不同的系统不同的处理方式。标准化是运维平台的基础没有标准化就没有运维平台。2. 平台化 传统的手工运维方式需要投入大量人力效率低容易出错因此需要在运维标准化的基础上将运维的相关操作都集成到运维平台中通过运维平台来完成运维工作。运维平台的好处有可以将运维标准固化到平台中无须运维人员死记硬背运维标准。运维平台提供简单方便的操作相比之下人工操作低效且容易出错。运维平台是可复用的一套运维平台可以支撑几百上千个业务系统。3. 自动化 传统手工运维方式效率低下的一个主要原因就是要执行大量重复的操作运维平台可以将这些重复操作固化下来由系统自动完成。例如一次手工部署需要登录机器、上传包、解压包、备份旧系统、覆盖旧系统、启动新系统这个过程中需要执行大量的重复或者类似的操作。有了运维平台后平台需要提供自动化的能力完成上述操作部署人员只需要在最开始单击“开始部署”按钮系统部署完成后通知部署人员即可。类似的还有监控有了运维平台后运维平台可以实时收集数据并进行初步分析当发现数据异常时自动发出告警无须运维人员盯着数据看或者写一大堆“grep awk sed”来分析日志才能发现问题。4. 可视化 运维平台有非常多的数据如果全部通过人工去查询数据再来判断则效率很低。尤其是在故障应急时时间就是生命处理问题都是争分夺秒能减少 1 分钟的时间就可能挽回几十万元的损失可视化的主要目的就是为了提升数据查看效率。可视化相比简单的数据罗列具备下面这些优点能够直观地看到数据的相关属性例如汽车仪表盘中的数据最小值是 0最大是 100单位是 MPH。能够将数据的含义展示出来例如汽车仪表盘中不同速度的颜色指示。能够将关联数据整合一起展示例如汽车仪表盘的速度和里程。测试平台 测试平台核心的职责当然就是测试了包括单元测试、集成测试、接口测试、性能测试等都可以在测试平台来完成。测试平台的核心目的是提升测试效率从而提升产品质量其设计关键就是自动化。传统的测试方式是测试人员手工执行测试用例测试效率低重复的工作多。通过测试平台提供的自动化能力测试用例能够重复执行无须人工参与大大提升了测试效率。为了达到“自动化”的目标测试平台的基本架构如下图所示。1. 用例管理 测试自动化的主要手段就是通过脚本或者代码来进行测试例如单元测试用例是代码、接口测试用例可以用 Python 来写、可靠性测试用例可以用 Shell 来写。为了能够重复执行这些测试用例测试平台需要将用例管理起来管理的维度包括业务、系统、测试类型、用例代码。例如网购业务的订单系统的接口测试用例。2. 资源管理 测试用例要放到具体的运行环境中才能真正执行运行环境包括硬件(服务器、手机、平板电脑等)、软件(操作系统、数据库、Java 虚拟机等)、业务系统(被测试的系统)。除了性能测试一般的自动化测试对性能要求不高所以为了提升资源利用率大部分的测试平台都会使用虚拟技术来充分利用硬件资源如虚拟机、Docker 等技术。3. 任务管理 任务管理的主要职责是将测试用例分配到具体的资源上执行跟踪任务的执行情况。任务管理是测试平台设计的核心它将测试平台的各个部分串联起来从而完成自动化测试。4. 数据管理 测试任务执行完成后需要记录各种相关的数据(例如执行时间、执行结果、用例执行期间的 CPU、内存占用情况等)这些数据具备下面这些作用展现当前用例的执行情况。作为历史数据方便后续的测试与历史数据进行对比从而发现明显的变化趋势。作为大数据的一部分可以基于测试的任务数据进行一些数据挖掘。数据平台数据平台的核心职责主要包括三部分数据管理、数据分析和数据应用。每一部分又包含更多的细分领域详细的数据平台架构如下图所示。1. 数据管理 数据管理包含数据采集、数据存储、数据访问和数据安全四个核心职责是数据平台的基础功能。数据采集从业务系统搜集各类数据。例如日志、用户行为、业务数据等将这些数据传送到数据平台。数据存储将从业务系统采集的数据存储到数据平台用于后续数据分析。数据访问负责对外提供各种协议用于读写数据。例如SQL、Hive、Key-Value 等读写协议。数据安全通常情况下数据平台都是多个业务共享的部分业务敏感数据需要加以保护防止被其他业务读取甚至修改因此需要设计数据安全策略来保护数据。2. 数据分析 数据分析包括数据统计、数据挖掘、机器学习、深度学习等几个细分领域。数据统计根据原始数据统计出相关的总览数据。例如PV、UV、交易额等。数据挖掘数据挖掘这个概念本身含义可以很广为了与机器学习和深度学习区分开这里的数据挖掘主要是指传统的数据挖掘方式。例如有经验的数据分析人员基于数据仓库构建一系列规则来对数据进行分析从而发现一些隐含的规律、现象、问题等经典的数据挖掘案例就是沃尔玛的啤酒与尿布的关联关系的发现。机器学习、深度学习机器学习和深度学习属于数据挖掘的一种具体实现方式由于其实现方式与传统的数据挖掘方式差异较大因此数据平台在实现机器学习和深度学习时需要针对机器学习和深度学习独立进行设计。3. 数据应用数据应用很广泛既包括在线业务也包括离线业务。例如推荐、广告等属于在线应用报表、欺诈检测、异常检测等属于离线应用。数据应用能够发挥价值的前提是需要有“大数据”只有当数据的规模达到一定程度基于数据的分析、挖掘才能发现有价值的规律、现象、问题等。如果数据没有达到一定规模通常情况下做好数据统计就足够了尤其是很多初创企业无须一开始就参考 BAT 来构建自己的数据平台。管理平台管理平台的核心职责就是权限管理无论是业务系统(例如淘宝网)、中间件系统(例如消息队列 Kafka)还是平台系统(例如运维平台)都需要进行管理。如果每个系统都自己来实现权限管理效率太低重复工作很多因此需要统一的管理平台来管理所有的系统的权限。权限管理主要分为两部分身份认证、权限控制其基本架构如下图所示。1. 身份认证 确定当前的操作人员身份防止非法人员进入系统。例如不允许匿名用户进入系统。为了避免每个系统都自己来管理用户通常情况下都会使用企业账号来做统一认证和登录。2. 权限控制 根据操作人员的身份确定操作权限防止未经授权的人员进行操作。例如不允许研发人员进入财务系统查看别人的工资。上一章: 架构技术演进方向下一章: 架构重构技术归类: 从0开始学架构