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

单机部署

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

站库分离

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

文件系统

业务量再次增大，此时访问的瓶颈通常是静态的文件，大量与服务应用无关的文件存储在应用服务器上，例如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.