在介绍架构之前，为了避免一些读者不理解架构设计中的一些概念，以下是一些最基本的概念。
1）什么是分发？
系统中的多个模块部署在不同的服务器上，可称为分布式系统。例如，Tomcat和数据库部署在不同的服务器上，或者两个具有相同功能的Tomcats部署在不同的服务器上。
2）什么是高可用性？
当系统中的某些节点发生故障时，其他节点可以接管并继续提供服务，则可以认为系统具有高可用性。
3）什么是集群？
特定于域的软件部署在多个服务器上，并提供一类服务作为整体，统称为集群。
例如，Zookeeper中的Master和Slave部署在多个服务器上以形成集中配置服务。
在公共集群中，客户端通常可以连接到任何节点以获取服务，并且当集群中的一个节点脱机时，其他节点可以自动接管并继续提供服务。这表明群集具有高可用性。
4）什么是负载平衡？
当请求发送到系统时，请求以某种方式均匀分布到多个节点，这样系统中的每个节点都可以统一处理请求负载，系统可以视为负载均衡。
5）什么是正向和反向代理？
当内部网络要访问外部网络时，请求将通过代理服务器转发。外部网络似乎是代理发起的访问。此时，代理服务器实现转发代理。
当外部请求进入系统时，代理服务器将请求转发到系统中的服务器。对于外部请求，只有代理服务器与之交互，代理服务器实现反向代理。
简单来说，转发代理是代理服务器替换系统内部以访问外部网络的过程，反向代理是当外部请求访问外部请求时通过代理服务器转发到内部服务器的过程。系统。
3，纯粹时代：独立架构
以淘宝为例：在网站的开头，应用程序和用户较少，您可以在同一台服务器上部署Tomcat和数据库。当浏览器向www.taobao.com发起请求时，域名首先通过DNS服务器（域名系统）转换为实际IP地址10.102.4.1，浏览器访问与IP对应的Tomcat。架构瓶颈：随着用户数量的增长，Tomcat与数据库之间的资源竞争单机性能以支持业务。
4，第一次演变：Tomcat和数据库分开部署
Tomcat和数据库分别占用服务器资源，显着提高了各自的性能。
架构瓶颈：随着用户数量的增长，并发读写数据库成为瓶颈。
5，第二次演变：引入本地缓存和分布式缓存
在Tomcat或JVM上向服务器添加本地缓存，并在外部添加分布式缓存，缓存流行产品信息或热门产品的html页面。通过缓存，可以在读取和写入数据库之前拦截大多数请求，从而大大降低数据库压力。涉及的技术包括将memcached用作本地缓存，将Redis用作分布式缓存。它还涉及缓存一致性，缓存渗透/故障，缓存雪崩和热数据集失效等问题。
架构瓶颈：缓存可抵御大多数访问请求。随着用户数量的增长，并发压力主要落在独立的Tomcat上，响应逐渐减慢。
6，第三次演变：引入反向代理实现负载均衡
Tomcat部署在多个服务器上，反向代理软件（Nginx）用于将请求均匀分配给每个Tomcat。这假设Tomcat最多支持100个并发，而Nginx最多支持50,000个并发。从理论上讲，Nginx可以向500只雄猫分发请求，可以抵抗50,000个并发。
涉及的技术包括：Nginx，HAProxy，它们都是在网络第七层工作的反向代理软件，主要支持http协议，还涉及会话共享，文件上传和下载。
体系结构瓶颈：反向代理大大增加了应用程序服务器可以支持的并发数量，但并发性的增加也意味着更多请求渗透到数据库中，并且单机数据库最终成为瓶颈。
7，第四次演变：数据库读写分离
数据库分为读库和写库。可能存在多个读取库，并且写入库的数据通过同步机制与读取库同步。对于需要查询最新写入数据的场景，可以在缓存中写入一个副本。缓存获取最新数据。涉及的技术包括：Mycat，它是一个数据库中间件，可用于组织数据库以进行单独的读写和子数据库子表。客户端通过它访问底层数据库，还涉及数据同步和数据一致性。
架构瓶颈：企业变得越来越多样化，不同服务之间的差距也很大。不同的服务直接与数据库竞争并影响彼此的性能。
8，第五次演变：数据库按业务划分把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。
架构瓶颈：随着用户数的增长，单机的写库会逐渐会达到性能瓶颈。
9，第六次演进：把大表拆分为小表
比如针对评论数据，可按照商品ID进行散列，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。
这种做法显着的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。
XX
目前，开源和商业中有许多MPP数据库。开源中流行的包括Greenplum，TiDB，Postgresql XC，HAWQ等。商用，如Nanda General的GBase，瑞帆科技的Snowball DB，华为的LibrA等。不同的MPP数据库有不同的侧重点。例如，TiDB更多地关注分布式OLTP场景。 Greenplum专注于分布式OLAP场景。这些MPP数据库基本上提供了Postgresql，Oracle和MySQL等SQL标准支持功能。它可以将查询解析为分布式执行计划，并将其分发到每台计算机以进行并行执行。最后，数据库本身汇总了返回的数据。它还提供权限管理，子数据库子表，事务，数据复制等功能。支持100多个节点的集群大大降低了数据库操作和维护的成本，并使数据库能够水平扩展。
架构瓶颈：数据库和Tomcat都可以横向扩展，可支持的并发性大大提高。随着用户数量的增长，最终的独立Nginx将成为瓶颈。10，第七次演变：使用LVS或F5来平衡多个Nginx负载
由于瓶颈在Nginx中，因此不可能通过两层Nginx实现多个Nginx的负载平衡。图中的LVS和F5是在网络的第四层上工作的负载平衡解决方案。 LVS是在操作系统内核状态下运行的软件，它可以转发TCP请求或更高级别的网络协议，因此支持的协议更丰富，性能远高于Nginx，可以假设单个LVS可以支持成千上万的并发请求转发； F5是一种负载均衡硬件，类似于LVS提供的功能，性能高于LVS，但价格昂贵。由于LVS是软件的独立版本，如果LVS所在的服务器关闭，整个后端系统将无法访问，因此需要备用节点。您可以使用keepalived软件模拟虚拟IP，然后将虚拟IP绑定到多个LVS服务器。当浏览器访问虚拟IP时，它将被路由器重定向到真正的LVS服务器。当主LVS服务器关闭时，keepalived软件将自动更新路由器中的路由表，并将虚拟IP重定向到另一个正常的LVS服务器，从而实现LVS服务器的高可用性。
这里应该注意的是，上图中从Nginx层到Tomcat层的绘制并不意味着所有Nginx都会将请求转发给所有Tomcat。在实际使用中，它可能是Nginx下的一些Tomcats。这些Nginx高可用性是通过keepalived实现的，而其他Nginx连接到另一个Tomcat，因此可以访问的Tomcats数量可以成倍增加。
架构瓶颈：由于LVS也是独立的，随着并发连接数量增长到数十万，LVS服务器最终将达到瓶颈。此时，用户数量达到数十亿甚至数亿。用户分布在不同的区域和距服务器机房的距离。访问的差异明显不同。
11，第八次演变：通过DNS轮询实现机房的负载均衡
可以在DNS服务器中配置域名以对应多个IP地址，并且每个IP地址对应于不同机房中的虚拟IP地址。当用户访问www.taobao.com时，DNS服务器使用轮询策略或其他策略来选择用于用户访问的IP。这样，可以实现机房的负载平衡。此时，系统可以实现机房水平的水平扩展，并且可以通过增加机房来解决1000万到1亿的并发数量。系统入口处的请求并发不再是问题。
架构瓶颈：随着数据的丰富性和业务的发展，检索和分析的要求越来越丰富，单靠数据库无法解决如此丰富的需求。12，第九次演变：引入NoSQL数据库和搜索引擎技术
当数据库中的数据超过一定大小时，数据库不适合复杂查询，并且通常只满足普通查询的情况。对于统计报告方案，当数据量很大时，结果可能无法用完，而在运行复杂查询时，其他查询可能会变慢。对于全文搜索，可变数据结构等，数据库不适合自然使用。因此，有必要为特定场景引入合适的解决方案。对于海量文件存储，可以通过分布式文件系统HDFS解决。对于键值类型数据，可以通过HBase和Redis解决。对于全文搜索场景，可以通过搜索引擎（如ElasticSearch）来解决。对于多维分析场景，通过Kylin或Druid等解决方案解决。
当然，引入更多组件会增加系统的复杂性，不同组件存储的数据需要同步，需要考虑一致性问题，并且需要更多的操作和维护手段来管理这些组件。
架构瓶颈：引入更多组件来解决丰富的需求，业务维度可以大大扩展，结果是应用程序包含太多的业务代码，并且业务的升级迭代变得困难。
13，第十次演变：大型应用程序拆分成小型应用程序
根据业务部分划分应用程序代码，以便单个应用程序的职责更加清晰，彼此可以独立升级和迭代。此时，应用程序之间可能涉及一些常见配置，这可以由分布式配置中心Zookeeper解决。
架构瓶颈：不同应用程序之间存在共享模块。如果单独管理应用程序，则会生成相同代码的多个副本，这将导致在升级公共功能时升级所有应用程序代码。
14.第十一次演变：多路复用的功能被转移到微服务中
如果在多个应用程序中存在诸如用户管理，订单，支付和认证之类的功能，则可以单独提取这些功能的代码以形成要管理的单独服务。这些服务是所谓的微服务，应用程序和服务。公共服务以多种方式访问，包括HTTP，TCP或RPC请求，每个单独的服务可由单独的团队管理。此外，Dubbo和SpringCloud等服务可用于实施服务治理，限流，融合和降级，以提高服务稳定性和可用性。
架构瓶颈：不同的服务具有不同的接口访问方法。应用程序代码需要适应多种访问方法才能使用服务。另外，应用程序访问服务，服务也可能相互访问，调用链将变得非常复杂，并且逻辑变得混乱。
15.第十二次演进：企业服务总线ESB屏蔽服务接口引入的访问差异通过ESB统一接入协议转换，应用程序通过ESB统一访问后端服务，服务和服务也通过ESB相互调用，从而降低了系统的耦合度。
上海IT外包服务网 链接：http://www.linemore.com
中文
电话咨询
微信咨询
公众号
