作者：潘罡 （Van Pan） @ Microsoft

在正式介绍Service Fabric之前，我们认为应该首先介绍分布式系统的经典架构。

理解了分布式系统的演进过程可以极大程度上帮助理解Service Fabric以及Azure服务中所有针对分布式系统的优秀产品。

简单系统模型

在IT时代初期，如果需要自行构建一个系统，需要完成以下工作。

• 采购服务器
• 在服务器中安装Web服务器
• 在服务器中安装数据库
• 向ISP申请静态IP
• 向服务器部署静态IP
• 向服务器中部署网站
• 向服务器中部署数据库原始数据
• 向域名供应商购买域名
• 将域名和静态IP进行绑定
• 向证书供应商购买证书
• 向服务器中部署证书
• 对Web服务器配置证书，监听域名等
• 网站启动外部服务监听，比如HTTP，HTTPS

经典分布式模型

随着网站访问量逐渐增加，系统压力逐渐上升。

此时根据实际情况不同，会对站点服务器做以下调整。

• 使用性能更好的服务器，简称垂直升级。该做法已经不是主流做法，除非在无法实现下列解决方案前提下才会考虑。
• 数据库迁移至单独服务器。
• 数据库水平升级
  • 数据库主从分离，读写分离。使用单独服务器作为写服务器，其他服务器作为读服务器。成熟数据库都可以配置主从分离。
  • 数据库垂直拆分。将数据库数据不同的表放到不同的服务器。
  • 数据库水平拆分。将数据库表根据特征拆分至不同表。比如2016年数据和2017年数据分表存储。
• Web服务器垂直拆分，将子系统拆分至单独服务器
• Web服务器负载均衡，有以下几种做法
  • 动态域名解析
    • 将服务器放置在不同物理地域。比如北京上海两台服务器分别针对华南华北用户。对于同一个域名，华南华北用户解析到的服务器IP不同。
    • 同一台服务器，不同ISP线路优化。有些机房有电信联通双线。网站管理员申请电信联通不同IP，用户在电信联通环境下针对同一个域名解析到不同IP。
    • 同域名多IP负载均衡。即使是同一个ISP，同一个机房的服务器，也可以通过动态域名解析返回多个不同IP。用户的请求会在不同IP间切换，同样达到了负载均衡效果。
  • 网络负载均衡
    • 硬件负载均衡。商业负载均衡服务器，例如F5。从硬件层面将网络连接负载均衡至不同后台Web服务器。
    • 软件负载均衡。现在有大量开源反向代理服务器，例如Nginx。使用该服务可以在前端监听端口，并且将请求分发至后台的不同服务器。

当服务器面临突发的请求压力（可能是被DDos攻击，也可能是因为业务营销活动，比如双十一），客户开始电话轰炸站点卡死不可用，如何快速解决问题？

如果发现是数据库压力过大，应该怎么办？

对数据库进行拆分吗？

这几乎是不可能的，因为数据库的任何改动都会反向影响代码修改。而且拆分数据库需要大量的时间。

比较可行的解决方案，有以下几种。

• 部署新的读数据库服务器，减少当前数据库服务器承担的并发压力
• 关闭一部分线上功能，减少数据库整体请求

当然最完美的解决方案，就是数据库设计本身就是针对分布式的。

如果数据库也可以动态扩容，就不会遇到数据库性能瓶颈。

如果发现是Web服务器压力过大，应该怎么办？

最行之有效的方法就是通过网络负载均衡添加服务器。

但这又引入了另一个问题。

• 通常情况下，Web服务器的性能瓶颈通常都是由某个部件导致的，仅仅针对这个组件，就需要部署一整套Web服务，看起来非常不合理。
• 因为现在服务器压力很大，所以完全不知道需要部署多少台服务器才够支撑。
• 每台服务器都需要做相同的部署操作，简陋一点是每台都需要人工操作，高级一些是部署脚本，但是因为新增加了服务器，都需要修改负载均衡配置。

如果有某种解决方案，可以准确定位性能瓶颈组件，并且在服务器自动增加后自动扩展该组件，就可以同时解决自动化以及经济性需求。

在下一节中，我们将会详细介绍在现在的云服务环境中，分布式系统的演进以及系统架构师对于分布式系统更深的理解。

在掌握了云时代分布式系统的最新概念后，才能理解Service Fabric中所有抽象概念以及使用场景。

经典分布式系统设计