系统的架构很重要，不同的架构解决了不同的系统承载量，就像大桥一样，采用的架构不一样，大桥的承载也不一样，软件系统也是一样，今天带大家一起了解一下最常用的几种系统架构。
一、单机单应用
这是最常见的入门架构，将数据库、web服务、静态资源、图片服务全部放在一台服务器上，这种架构比较适合访问量比较小的个人博客、企业官网等优势：单一部署，降低成本
缺点：并发访问量不高
二、多机分发
多机分发指的是将不同的服务放在不同的服务器上，避免相互影响，独立运行，例如将服务器放在单独的服务器上，web服务放在另外一台服务器上，静态资源放在一台服务器上做cdn加速，用户上传的图片放置在单独的图片服务器上，各个模块独立开来，并发量比单机一体化要高一些，这种模式一般用在内容分发系统上，如新闻系统，后台将新闻添加上动态生成静态资源防置在cdn上，距离最近的用户可以急速访问到这个页面的资源，加快页面的加载速度。优势：模块相对独立互不影响
缺点：并发量有限，有瓶颈
三、负载均衡+分表分库+集群+多级缓存
当访问量上来之后，我们发现单台服务器的性能已经无法满足需求，这个时候怎么办，加服务器，做负载均衡，web层增加服务器进行负载均衡，图片css js资源做cdn加速等。但是如果瓶颈出在数据库的话，那就要进行分表分库，将单一的数据库中的表按进行分库分表，例如将订单表放在单独的一组服务器上进行集群，读写分离，订单按照日期进行分表，今天的表叫order20191212，那么明天的订单表就叫order20191213，以此类推，用户表放在单独的数据库服务器上，是否进行集群主要根据对表访问量的大小，另外增加多级缓存，在api接口及客户端上增加缓存机制，提高缓存的命中率。
优点：数据库分离，便于维护，提高了并发量和缓存的命中率
缺点：数据库瓶颈，访问高峰期超过系统最大承载量容易造成瘫痪
四、微服务+SOA治理+异步处理+多级缓存
三的架构已经拆的很细了，但是一旦出现异常大流量高峰，极易出现系统瘫痪，那么我们在三的基础上改进，进行SOA+微服务+异步处理，SOA就是面向服务治理的一个架构，服务消费方与服务提供方独立，通过一个机制，服务器消费房访问服务提供方，服务消费的形式分同步和异步，同步就是消费端发出服务器请求，服务监管者会获取这个请求，查询已经注册登记此类的服务的服务方，并按照权重返回给服务消费者，消费者根据权重来访问服务提供方的url地址，并且等待服务提供方的处理结果，如果是异步的话，服务器消费者发出请求后，立即访问，等待服务器提供方处理完后异步通知服务消费者，这样在高并发的情况下，服务提供方不会造成瞬时高并发访问系统过载的瘫痪情况，消费者将消费请求放入队列，然后服务器提供方从队列获取进行消费即可。12306就是采用这种架构，订单模块采用消息队列进行异步处理，通过多级缓存解决用户的查询需求。优点：SOA治理服务，让服务而更高效清晰及时，异步处理让系统承载量提升。
缺点：高并发下系统处理会变慢，需要的服务器很多，闲时会造成资源浪费。
五、serverless弹性伸缩
四的架构已经能满足大型系统的访问了，但是前提是要预估系统的承载量，然后按照承载量来计算所需的资源，当系统不忙的时候会出现资源闲置浪费的情况发生，那么如果服务消费端与调用端能根据系统的当前访问量进行自动调整，闲的时候释放资源，忙的时候增加资源，进行弹性伸缩，是不是很好呢，是的，这里就要使用serverless，他能够根据预先指定的策略动态调用运算资源，应该各种情况下的用户访问量。淘宝和支付宝天猫的架构就是这一层了。优点：弹性伸缩，需要云端支持
缺点：系统改造比较复杂，对于技术要求高
{{collectdata}}
网友评论0