计算机软件架构发展历史(一）

• 软件架构初识
• • 概述
  • 基本概念
• 软件架构演进过程
• • 单体架构初步设计
  • Web服务与数据库分开
  • 本地缓存和分布式缓存
  • 反向代理与负载均衡设计
  • 数据库读写分离设计
  • 数据库按业务进行分库
  • 大表拆分为小表
  • LVS或F5让多个Nginx负载均衡
  • DNS轮询实现机房的负载均衡
  • 大应用拆分成小应用
  • 抽离微服务实现工程复用
  • 容器化技术设计及应用
  • 云平台服务部署
• 总结(Summary)
• • 重难点分析
  • FAQ分析
  • Bug分析

软件架构初识

概述

为了更好理解互联网软件架构，我们现在介绍一下，一百万到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知。

基本概念

在介绍架构之前，为了避免初学者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍。

分布式

系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上。

高可用

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。保证系统的高可用性，可从如下几个9说起，如图所示：

软件架构演进过程

单体架构初步设计

在互联网应用初期，互联网用户数相对都较少，可以把web服务器(例如Tomcat)和数据库部署在同一台服务器上。浏览器往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat。如图所示：

在这种架构下，随着用户数的增长，并发读写数据库的操作也会越来越多，此时数据库的读写方面就产生性能瓶颈问题（数据库支持的连接数是有限的，连接用尽时，其它用户就会阻塞，同时频繁磁盘读写也会使系统性越来越差）,并发读写数据库成为瓶颈。

本地缓存和分布式缓存

如何降低数据库的访问压力呢，无非就是减少对数据库的访问。此时，我们可以考虑应用缓存（cache）。例如，在Tomcat同服务器上增加本地缓存，并在外部增加分布式缓存，缓存一些相对热门的数据（热门商品信息或热门商品的html页面等）。通过缓存把绝大多数请求在读写数据库前拦截掉，这样降低数据库的访问频次，读写压力。提高请求响应速度。如图所示：

反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈。

数据库读写分离设计

当一个tomcat服务无法处理更多并发时，我们就使用多个tomcat，分别部署在多台服务器上。然后，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中。此处假设Tomcat最多支持100个并发，Nginx最多支持50000个并发，那么理论上Nginx把请求分发到500个Tomcat上，就能抗住50000个并发。如图所示：

这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。对于这种方案，随着用户数的增长，单机的写库会逐渐会达到性能瓶颈。

大表拆分为小表

比如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。

其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。
此种方案中，由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同。

DNS轮询实现机房的负载均衡

在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级。

抽离微服务实现工程复用

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。如图所示：

在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在3.14节之前，服务运行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被破坏）。

云平台服务部署

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。

总结(Summary)

重难点分析

• 发展历程中的关键设计及技能点。
• 架构发展过程中暴露出的问题以及解决方案。

FAQ分析

• 单体架构你觉得存在什么缺陷容量、计算、故障）
• 为什么要使用分布式架构增加容量、高并发、高性能、高可用)
• 分布式架构有什么劣势设计的难度、维护成本)
• 为什么要使用缓存减少数据库访问压力、提高性能)
• 使用缓存时要注意什么问题一致性、淘汰算法、击穿、雪崩)
• 如何理解反向代理服务端代理，是服务端服务器的一种代理机制，请求转发)
• 反向代理如何实现负载均衡轮询，轮询+权重，哈希IP)
• 什么是读写分离、读写分离的目的是什么单机数据库有瓶颈、读写频次，并发能力)
• 读写分离后可能会带来什么问题数据同步）
• 当我们向写库写数据时还要做什么写缓存、数据同步到读库)
• 为什么要进行分库、分表，有哪些分表策略业务数据可靠性、查询性能)
• 何为服务，有什么是微服务服务-软件要解决的问题，可以提供的功能。微服务-服务中的共性再抽象，以实现更好的重用)
• 哪种互联网架构设计最好没有最好，只有更好，脱离业务谈就够就是耍流氓)

Bug分析

• 。。。。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91338 人正在系统学习中

来源：雨田说码