Scalability对于软件设计师来说永远都是一种挑战，虽然我们设计的系统并不一定都要有Scalibility的能力但是客户往往都有这方面的期待，因为每个客户都希望自己的业务能够做大，都希望自己的数据库可以与Myspace一样大。最近要和lvke兄弟合作写一些对于数据库的东西，这里也和大家分享一下自己的体会。
Session 1
What is Scalability?
扩展性就是说我们需要让应用程序可以使用更多的资源去做更多的工作。简单的说就是随着业务增加，应用程序将承担更多的负载，这个时候我们需要对于应用程序使用的资源进行调整，用来处理这些负载，这是我们的应用程序能否有能力的利用这些增加的资源，这就是Scalability。
对于应用程序来说，我们可通过减低组件的耦合程度将组件分层并部署到不同的服务器上，同时考虑每层组件对于NLB的支持，这样就可形成一个云，每层服务组件都可能由若干服务器来运行，当负载增加时可以通过增加服务器的方式来进行横向的扩展，多数的互联网企业都是这种思路。
对于Scalability来说，通常用2种方式实现-Scale Up和Scale Out。对于不同的环境和要求来说，正确的使用相应的策略才是最关键的。Scale up就是提供更强大的服务器来提供更好的性能，如果你的软件系统可以支持更多的CUP和内存，Scale up也是一个不错的方式。但是目前的服务器的处理能力受到很多技术上的限制，并不是说我们可以无限制的添加资源，同时我们的软件系统也并不一定可以支持这么多的CPU和内存，不论你是Windows或Unix。同时更大的服务器也意味着更高的成本。这时人们更多的是想到Scale out的方案。Scale out方案就是利用N个廉价的服务器去处理更多的业务，业务增加时可通过增加服务器来实现业务的处理，这样从理论上我们可以不去限制服务器的数量，互联网应用就是典型的Scale out，当然互联网行业有他特定的行业特点。
应用程序中很多情况下离不开数据库的支撑，除非你是Google，有能力自己去编写适应与自己业务的数据库。通常情况下我们都会采用一些商业或开源的数据库产品来实现我们对于数据持久和查询的功能。我遇到了很多客户在进行产品选型的时候都会说我们要求你们的数据库可以实现负载均衡等类似的要求，大家也都知道数据库上的均衡方式不同于我们Web服务器的均衡，我们要考虑到数据的同步、事务等更多的方面。长期以来很多用户都在诟病SQL Server无法做到Load Balance，而Oracle的RAC却可以实现。我稍微看了一下Oracle的RAC，从原理上他也无法实现类似于服务器云的那种形态，因为RAC其实是一个Cluster，需要共享网络总线和磁盘系统，网络总线用于同步Cache，共享SAN用于存储数据。SQL Server虽然也能实现Cluster，但是A/A群集上的2个实例还是无法做到对于性能有什么提升。当然RAC也不是没有缺陷，当节点数大于2个的时候性能并不是按照我们想象的一样按照线形增长，而且当节点数持续增加的时候网络可能就会成为最大的瓶颈，而且在国内目前看到的RAC也只是以2个节点的为多，更多节点的RAC目前在国内也没有太多成功的案例。回来继续谈谈SQL Server，虽然By default，没有RAC的功能，但是并不是代表不能做到，MySpace有数百台SQL Server支撑网站，形成一个数据库服务器云，可以通过增加数据库服务器来支撑用户数量的增加，还有像纳斯达克这样的应用场景也都是存在类似的方案。所以说能和不能并不是重要的，系统地架构设计+产品的功能也能帮我们实现数据库服务器的Scale out。
目前我们在SQL Server上的Scale out Solutiion主要有以下几种
- Scalable Shared Database
- Peer-to-Peer Replication
- Linked Servers and Distributed Queries
- Distributed Partitioned Views(DPV)
- Data-Dependet Routing
- SOA
后续的文章我会慢慢的聊聊这些Solution，时间所限可能会很慢很慢很慢。。。。
打印 | 张贴于 2008-05-08 15:14:48 | Tag:暂无标签
留言反馈