经典分布式系统设计

做者：潘罡 （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中全部抽象概念以及使用场景。