最近看了一些有关架构的书籍和博文,感悟很深,现在我就来说说自己的想法。

单机部署

在企业最初开发的时候,通常仅仅是单机部署,此时业务量较小,单台服务器上面部署了服务应用和数据库,完全可以承受业务访问。

站库分离

而在业务量访问不断增大的时候,数据库性能成为了瓶颈,此时就应该单独将数据库剥离出来,使用单台服务器部署数据库,此时的架构则是站库分离的。

文件系统

业务量再次增大,此时访问的瓶颈通常是静态的文件,大量与服务应用无关的文件存储在应用服务器上,例如js文件,图片文件,这些都会占用应用服务器的带宽和性能,此时应将文件系统剥离为单独的服务,目前比较建议的方案是各类云服务提供商提供的对象存储功能,或者可以考虑自建目前比较主流的文件分布式系统例如:GlusterFS、ceph、Lustre、FastDFS

负载均衡

用户的访问量再一次提升时,单台应用服务器已经无法承受这么多的用户同时进行访问了,这时候就应该进行负载均衡的设计,但是负载均衡的方案,用户的会话保持会是一个问题,通常可以考虑使用一个第三方的方案来保持用户的会话,比如使用Redis来保持用户的会话,至于负载均衡的方案,目前使用的较多的是Nginx及其各类开源版本

CDN技术

负载均衡及文件系统都能提升用户容量,但通常用户的网络不固定,例如他可能现在在用移动网络,然后突然切换到Wifi网络,此时wifi网络例如是长城宽带,服务器的带宽是电信宽带,这时候的速度可能就会略微慢一些,用户的体验会受到一定的影响。此时CDN技术就派上用场了,使用CDN技术来缓存文件,服务器只需要发送页面文件,甚至你可以将页面部署到CDN,前提是页面是静态的HTML,此时服务器只需要接收用户的请求与反馈响应即可,带宽压力减小,性能也有一定的提升。

DNS轮询

其实DNS轮询可以理解为高级负载均衡,其原理与负载均衡类似,每个用户发起请求之前,他都需要解析这个域名获取到服务器的IP,然后才会向服务器IP发送请求,这时候我们可以在域名解析处进行配置,例如noesblog.com这个域名,在电信的线路下配置2个服务器,在移动的线路下配置2个服务器,在HK的线路下将海外的请求配置到一个服务器。这时候如果一个用户从电信的线路下准备请求,这时候DNS会根据规则返回一个服务器的IP地址,这时候该用户就会请求这个服务器,这样就达到了用户的请求分流的效果。

集群

在之前其实我们已经介绍过了集群,例如在DNS轮询中我们提到了在不同网络情况下配置了好几个应用服务器IP,这时候他们就可以理解为一个应用服务器的集群。所谓集群的特点就是他们都是担任同一类职责,例如数据库集群,应用服务器集群,缓存服务器集群,图片服务器集群。

分布式

说到集群,那么几乎就会涉及到分布式,所谓的分布式系统就是将一组独立的计算机,展现给用户的却是一个统一的整体,而在分布式系统内部的调度与交互,则是通过网络来实现,分布式系统内的各个计算机,他们之间通过网络来进行交互,这个其实就是和之前提到的负载均衡方案需要保持用户会话,而如果我们使用Redis来保持用户会话,那么应用服务器和Redis服务器之间就会使用网络来进行通讯。但是分布式系统又会有一个问题,当系统架构变得十分复杂时,如何管理这些服务器之间的关系就变的十分令人头疼了,关于这方面,可以使用dubbo来解决,避免复杂架构手动管理出现失误的问题。

微服务

最近十分流行微服务这个词,原因是他不仅提升了系统的可扩展性,也十分有利于弹性的扩缩。在以往的开发中,用户的流量通常会在某一时段剧增,而在其他的时间只有一部分用户在访问,这时候我们购买的那一部分用于承担高峰流量用户的服务器,就白白浪费了,但是如果使用微服务架构,我们就可以利用比如云服务商提供的快速扩容的功能,降低企业的成本。
以一个简单的邮件发送功能为例,在之前的开发过程中,可能直接集成在应用服务中,也可能单独抽到个服务器进行部署,若某一时间段发送邮件的用户较多,单服务器无法承载,这时候就需要购买更多的服务器来部署邮件发送的服务。而在剩余的时间中,可能仅仅只需要一个邮件服务器就能承担用户发送邮件的任务。而当我们使用微服务架构时,我们可以直接将邮件发送的功能抽为一个单独的项目,其他系统如果需要邮件发送的功能,使用网络请求调用即可,而如果遇到较多的用户请求,可以直接新开一台服务器,或者在大型机上使用类似Docker的技术,直接新起更多的邮件发送服务,来承载用户的请求,这样一来降低了成本,二来使得整个系统的灵活性增加,避免了大多数服务器都是0负载的情况发生,而类似Docker这类应用的出现,从之前的分钟级的部署速度,可以加速到秒级的部署,这样就提升了整个系统的稳定性,可维护性。

异地多活

所谓的异地多活,其思路相信你已经明白了,就是将集中管理的服务器,在其他地方也会有相同的服务器,他们同样是为用户服务,且因为物理距离离用户更近,用户的体验就更好,例如北京的用户,最好是能够访问北京地区的服务,而不是去访问深圳地区的服务,上海的用户,可以优先访问浙江地区的服务器,而不是去访问成都地区的服务器。而即使其中一个区域的服务出现了故障,可以快速的将用户的请求重新定向到其他地区的服务器,保证服务的可用。、
但是异地多活就带来了一个更大的问题,数据中心之间如何保证数据的一致性,举个例子,用户A和B使用同一个账户在C地和D地同时购买价值100元的商品,而这个账户的余额只有100元,若数据中心中的数据不是完全同步的,那么两个数据中心就会认为他们都有足够的余额去支付这个商品,而实际上账户的余额仅能购买一件商品。因此数据中心之间的同步问题就变的令人十分的头疼,但我们仍旧可以参考计算机的设计,例如多核计算机是如何保证一个命令的原子性,参考这些来设计数据中心之间的同步性,那么设计数据中心的实现方式,就变得不那么困难了。

结语

看完以上的内容,相信你已经发现了,其中大部分的内容都是相辅相成的,例如一个文件系统可能扩充为多台服务器部署,此时他就是一个文件系统集群,而应用服务器若需和文件系统集群进行交互,那么他们就是一个分布式的架构,而这些看上去高深莫测的技术,其实大多可以在计算机的设计中找到,大道至深,皆归于0.

发表评论

电子邮件地址不会被公开。