总结分析构建高性能WEB系统相关经验与常用技术

自互联网发展以来，各种应用层出不穷，用户数量上亿。因此，如何构建一个优秀的高性能、高可靠的应用系统对每个开发者都至关重要。本文总结了我在工作中学到和使用的一些方法，希望对其他学生发挥一些参考作用，在未来的发展中遇到类似的问题，能够快速找到解决方案。我主要使用JAVA语言，所以下面没有特别说明。这是使用JAVA语言实现高性能的关键。为了实现高性能，我总结了三点：缓存DNS缓存数据库缓存分布式缓存拆分业务拆分数据库拆分异步网络异步磁盘异步使用新闻中列出了三点中的一些常见情况，无论你在哪里遇到性能瓶颈，记住这三点，大多数时候你都能找到解决方案。在整个架构的各个方面，我们应该首先考虑无状态对象。无状态对象可以简单地理解为无状态对象。例如，model/entity对象不属于无状态对象，因为它包含field，例如典型的MVC场景**Controller，**Service是无状态的，它们只含有method。有些也有状态，比如Structs2框架的Action，所以Structs2现在用的比较少。有些也是有状态的，比如Structs2框架的Action，所以Structs2现在很少使用。有了无状态对象，我们可以构建无状态服务，因为请求链路中没有状态对象，所以我们的每个请求都是独立的。这种结构有助于扩展我们的服务。无状态服务有时难免会遇到一些有状态的对象，比如最常见的是session。由于http请求本身是无状态的，因此cookie和session必须配合使用，才能多次识别http请求属于同一用户。一般有两种解决方案:使用cookie存储和使用分布式session服务。首先是将所有对象信息存储在cookie中，并通过相应的算法在服务端读取cookie中的信息。这些信息通常是加密的。第二种方法是将session存储在分布式数据库或分布式缓存中，通常存在redis或memcache中。这种服务扩展将依赖于第三方数据库或缓存的能力。淘宝有类似的组件，开源世界也有基于memcache和redis的分布式session无状态服务。拆分和缓存业务拆分可以扩大应用程序服务水平，但当单个应用程序太大太臃肿时，有必要拆分应用程序。垂直拆分是根据业务进行拆分，如电子商务系统、订单系统、积分系统等。拆分可以方便开发和扩展。系统大了之后，每个业务的访问量就不一样了。比如买家系统肯定比卖家系统大很多。这个时候只能增加买家系统的机器。除了根据不同的业务分为不同的系统外，我们的应用层也可以分为应用层、逻辑层和原子层。应用层是各种数据和逻辑业务的组装。逻辑层包含大量可重用的逻辑。原子层直接操作数据库，包括一些基本的数据操作。无论以何种形式拆分，拆分后的系统都会在物理层面上分离，因此系统之间的通信是拆分中最重要的问题。RPC在RPC服务之前有很多系统通信方式，比如RMI、WebService，然而，RPC现在已经成为主流的通信手段，以更方便、更高效的方式跨平台。几乎每个大公司都有自己的RPC框架：淘宝的HSF、SCF也有许多优秀的开源框架：Dubbo、GRPC、Thrift等等。国内也有很多大公司使用dubo:JD.COM和当当都是。MQRPC调用一般用于耦合重、同步调用的场景。MQ也被广泛应用于各种业务中，作为另一种异步通信手段。常用的有：ActiveMQ、RabbitMQ、Kafka、RocketMQ。前两种一般作为企业级应用，其主要特点是支持许多特点和规范。后两者是互联网级的，吞吐量更强，性能更高，但牺牲了很多MQ的特点。mq通常用于需要最终连续性的场景，如用户注册和积分发送。注册后，用户可以直接返回前台成功，然后向mq系统发送成功注册信息，发送积分动作订阅注册事件，消耗mq事件信息。MQ最大的优点是峰值切割和解耦，在RPC同步呼叫场景中，如果相同的逻辑呼叫A和B，那么在扩展中，A和B必须需要同时扩展，但消息后，A发送消息给B，B暂时不能处理，也可以等到B继续处理后的峰值，即使B短期不能匹配A发送消息的能力。一般来说，数据库拆分项目会经历数据量从小到大的变化，因此数据库拆分也会根据不同的数据量在不同的阶段进行相应的处理。读写分离是大多数应用在遇到性能瓶颈时首先要做的事情。大多数互联网应用程序都是阅读占道90%以上的场景。所以一主多从，一个master写，其他slave读。然而，这种主从模式也存在一些问题。例如，有些数据需要更及时，也就是说，它们需要在写入后立即阅读。由于主同步是通过log异步复制的，因此存在数据不一致的窗口。此时，必须强制读取主库，以确保数据的安全。开发时必须注意。垂直分割是将不同的业务放在不同的数据库中，以减少单个数据库的压力，提高整体性能。垂直分割应注意业务边界问题。边界问题是有一个表，感觉适合放在A和B库中。这取决于经验，不能考虑太多，因为事实上，无论你以前有多好，在应用程序迭代中，总会有更多的表找不到一个明确的边界。在业务模块划分中，这个问题也是如此。水平分割一般意味着sharding。将同一表中的不同字段分成不同的表，或根据hash或业务字段将同一表分成不同的片段。这通常需要DAL框架的支持，包括TDDL框架、Cobar、Mycat等。就像操作数据库一样，程序编写者通过框架拆分数据库是看不见的。但目前的DAL框架还没有达到这样的目的，特别是在跨库事务的情况下，一般需要以其他方式进行处理。跨库事务/分布式事务一般通过最终一致性解决，即不强迫ACID满足，允许数据不一致的时间窗口，但总会有一个时间点数据达到最终一致的状态。解决方案很多，但核心原理是一样的，无非是靠补偿。计算机世界有句名言：“计算机科学领域的任何问题都可以通过增加间接的中间层来解决。”缓存是中间层。有很多场景使用缓存，几乎所有你能想到的地方。在这里，我们将讨论两种常见的数据库数据缓存缓存，local和remote，一般来说，使用缓存是很麻烦的，因为虽然缓存很好，但维护缓存的更新和删除是非常麻烦的。一般缓存可分为读缓存(大多数场景)和写缓存(一般针对数据安全性较低的场景)。例如，当读取数据库中的数据并写入缓存时，下次读取数据时，可以直接读取缓存中的数据，从而大大降低数据库的压力。说起来很简单。事实上，有很多种架构。每个架构都有优点和缺点。你可以详细了解它们。写缓存，就是先把数据写进缓存里，然后持续一段时间，也会提高效率。这个方案的问题是，如果此时停机，部分数据会丢失，所以适用于数据安全性低的场景。虽然缓存速度很快，但除了维护和更新之外，内存也是一个昂贵的硬件。因此，除了在缓存中存储热点数据外，还需要其他方法来解决在一般缓存中维护数据的索引或主要字段用于列表显示的问题。对于大多数场景，我们的数据在一定时间内不会改变，或者即使改变，页面的一小部分也会改变，可以单独取出不变的部分进行静态。比如JD.COM商城的页面是静态的。静态化后，数据不需要每次从缓存或数据库中获取，然后封装成页面，而是直接要求返回静态页面，性能无疑有了很大的提升。除上述常用方法外，还有许多重要的方法：CDN加速DNS缓存页面缓存使用分布式存储使用多线程编写程序