应用好卡？
What？应用又又又崩溃了？
怎么让我们的应用扛住并发？
我觉得同学你有必要Get一下“新姿势”了
首先我们来了解下本文需要知道的基本概念：
（1）集群（一个软件部署在多台服务器，并作为一个整体，提供一类服务）
（2）分布式（系统中，多个模块在不同服务器上部署）
（3）高可用（系统中部分节点失效，其他节点能够接替它继续工作或有相应的处理预案）
（4）负载均衡（把请求均匀的发到多个节点上）
概念图解
集群
小饭店原来是一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系就是集群。
分布式
为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系就是分布式的,一个配菜师也忙不过来,有请了个配菜师,这两个配菜师的关系就是集群了。所以说有分布式的架构中可能有集群,但集群不等于有分布式。
架构的演进路线
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
集群应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以大道负载均衡，提升效率的目的。数据库瓶颈同样适用，分表分库就是不错的提升效率的方法。
微服务架构
当垂直应用越来越多，应用之间交互不可避免，此时将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
01
单机架构
瓶颈：用户增长，服务和数据库之间竞争资源，单机性能不足以支撑业务。
解决方式：需要考虑服务与数据库分离
02
服务和数据库分开部署（最常见架构）
服务和数据库分别独占服务器资源，显著提高两者各自性能
瓶颈：用户量增长，数据库并发读写，尤其是读，成为瓶颈。
解决方式：需要考虑引入缓存
03
引入缓存
在服务器上加入缓存，可以把绝大多数请求（尤其是查询请求）在访问数据库前拦截掉
缓存服务可以自己放在一个服务器，也可以多弄几台缓存服务器，配置成主从同步（提升可用性可以加上哨兵、集群等方式）。
瓶颈：用户数量增长，并发压力主要在单机的服务上，响应逐渐变慢。
解决方式：需要考虑负载均衡
04
集群
使用反向代理，将大量的用户请求，均匀分发到每个服务器中
瓶颈：应用服务器可支持的并发量大大增加，缓存能力也可以轻易扩展，并发量增长意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈。
解决方式：可采用分表分开、读写分离等数据库优化手段
05
数据库优化
读写分离
把数据库划分为读库和写库，其中读库可以有多个，通过同步机制把写库的数据同步到读库
瓶颈：业务逐渐变多，不同业务之间的访问量差距较大，不同业务之间直接竞争数据库，导致最后相互影响性能。
数据库按业务分库
把不同的业务数据保存到不同的数据库中，这样一来业务之间的资源竞争降低，访问量大的业务可以拓展更多的服务器。
瓶颈：用户数量增长，单机的写库会逐渐达到性能瓶颈。
数据库分片
把数据库进行分片，这种做法可以称作分布式数据库，但逻辑上仍然是一个完整的数据库
引入NoSQL数据库和搜索引擎
数据量多到一定规模的时候，关系型数据库不再适用，而且数据量较大的查询，关系型不一定能运行出结果。
对于海量数据的处理，可通过分布式文件系统HDFS来存储。
对于key-value类型的数据，可通过HBase、Redis等处理。
对于抓取查询，可通过ES等解决。
对于多维分析，通过kylin、Druid等解决。
引入更多的组件同时必然极大的提高系统复杂度，不同的组件的数据还需要同步，需要考虑一致性问题。
06
微服务
按照业务板块来划分应用，使单个应用的职责更清晰。
优势：
1、系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2、系统之间的耦合度降低，从而更易于系统扩展。我们可以针对性地扩展某些服务，就是子系统集群。
3、服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
劣势：不同应用之间，存在公用的模块，导致包含公共功能的部分在升级时，全部相关代码都可能要跟着升级，这将增大部署压力。
07
总结
从架构的演进角度来看，整体的架构演进都是朝着越来越轻量级，越来越灵活的应用方向发展的。甚至到近两年日渐成熟起来的Serverless（无服务）架构。从单体服务到分层的服务，再到面向服务、再到微服务甚至无服务这种发展趋势对于架构的挑战是越来越大的。
扫一扫
7014
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
