Web项目演化系列--开启分布式(分离数据层)

原本上一篇是打算写分离数据层的，但是在思考的过程当中发现分离数据层的时候，有一些操作是要依赖分布式锁的，因此先写了分布式锁。

对于有些项目的数据层提供的是业务接口的(返回业务所需的数据)，那么当数据层压力逐渐增大的时候，如需要使用缓存的时候，就需要开发人员去修改相应的数据接口使其使用缓存，缓存和各种数据查询接口交错在一起，整个数据层的代码变得非常混乱，连重构都无法进行，只能推倒重做。所以很多的文章中，在讲解数据层的时候，都是使用统一的数据接口，如：Find、Add、Save等，那么当需要缓存的时候，就可以在Find中直接扩展使其支持缓存，甚至可以引入缓存配置管理，对于不同的表之间进行可调度的缓存周期管理，使开发人员不需要知道缓存的存在，他们还是使用原先的Find，但是速度却更快了，又或者冷热数据管理、搜索引擎等，这便是大神们在经过多年开发总结下来的经验。

将数据层从项目中分离出来成为一个独立的项目，并将其发布于独立的服务器，相对于单机系统而言，有如下几个优点：

1、便于整合各方资源

2、降低成本

3、每个层的性能更加优秀且可伸缩性强，在不断增加的负荷下，可以便利的增加节点数量。

4、某些次服务层出现错误的时候，不会导致项目的整体瘫痪。

5、不同层次可用不同语言实现

有优点就有缺点，最大的缺点就是较单机系统而言，分布式系统更加复杂，不仅系统本身结构会变得复杂，不同组件间的网络会引入影响因素，调试困难等等。

虽然有不少的缺点，但是不去实践是不会发现另一番天地的，不去挑战看看永远都只是局限在单机系统上，也不用害怕会遇到哪些问题，毕竟只有发现问题之后，才能想办法解决，这是从书上无法学习到的，那么我们就开始今天的文章吧。

基础CRUD

数据层是提供于数据库进行操作的中间件，最基础的功能就是CRUD，单机系统当中，调用CRUD接口的时候，要么通过拼接SQL要么通过ORM直接连接数据库，而由于现在是分布式的，因此原先的调用方式就需要通过通信协议来实现了，假设原先的接口为：

public class DbResult  {      public bool Error { get; set; }        public object Data { get; set; }  }    public interface IDb  {      DbResult Find(Dictionary<string, object> query);        DbResult Add(object entity);        DbResult Save(object entity);        DbResult Remove(object entity);  }

数据层那端的Find是以Query Object模式实现的，具体的格式可以查看此文章--《 Query Object--查询对象模式(上) 》、《 Query Object--查询对象模式(下) 》。

这里的数据层项目，如果使用原先抽取的mvcHandler方式来实现，那么IService的派生类就需要使用HttpWebRequest来实现了，大致的实现思路就是将相应的方法最后转换成调用数据服务，Find实现代码如下：

public DbResult Find(Dictionary<string, object> query)  {      var url = string.Format("{0}/{1}/{2}", ConnectionUri, this.table, "find");      var req = (HttpWebRequest)HttpWebRequest.Create(url);      req.Method = "Post";      req.Accept = "text/plain, */*; q=0.01";      req.ContentType = "application/x-www-form-urlencoded; charset=UTF-8";      req.Timeout = 1000 * 30;      req.KeepAlive = true;      try      {          byte[] bytes = Encoding.UTF8.GetBytes(              JsonConvert.SerializeObject(query));          req.ContentLength = bytes.Length;          using (var reqStream = req.GetRequestStream())          {              Stream requestStream = req.GetRequestStream();              requestStream.Write(bytes, 0, bytes.Length);          }            var res = new DbResult();          using (var resp = (HttpWebResponse)req.GetResponse())          {              using (var respStream = resp.GetResponseStream())              {                  using (var reader = new StreamReader(respStream, Encoding.UTF8))                  {                      string respContent = reader.ReadToEnd();                      return JsonConvert.DeserializeObject(respContent);                  }              }          }      }      catch      {          return new DbResult { Error = true };      }  }

事务

有了基础的CRUD以后，接下来就要实现事务了，如果参考单机系统来实现事务的话，那么开启事务以后，如果业务层出现问题导致主机重启或宕机，那么数据层的事务将会无法关闭，从而引发问题。

因此需要使用其他的方式来实现，观察事务可以得出从事务开启到提交是一个整体，只有事务提交的时候才需要有状态来判定事务的执行情况，而事务开启时并可以不需要有执行结果的判定，因此可以将事务看成一个队列，而中间的每一个CUD操作可以看成是它的元素，而每一个操作需要知道对应的是哪个表、执行哪个操作以及相应的表数据即可，代码实现如下：

public class TransactionAction  {      public string Table { get; set; }        public string Name { get; set; }        public object Data { get; set; }  }    //IDb  public interface IDb  {      //其他省略        void BeginTx();        DbResult CommitTx();  }    //IDb实现  private List actions;    public void BeginTx()  {      this.actions = new List();  }    public DbResult CommitTx()  {      //http访问数据层并设置actions为null  }    public DbResult Add(object entity)  {      if (this.actions != null)      {          this.actions.Add(new TransactionAction          {              Name = "add",              Table = this.table,              Data = entity          });      }      else      {          //单个增加      }  }

结束语

到这里数据层的分离基本上就完成了，如果想要更高效的数据获取，可以将访问方式修改成socket，之所以不直接使用WPF或者webService是因为这都是基于C#来开发的，而且如果直接使用现成的框架来用的话，能学到的东西就不多了。

就到这里了，如果有什么问题或者错误的话，请给我留言，谢谢。