分布式系统设计新手入门---2，微服务架构中拆分的实践
引言
在这篇文章中将从分析一个开源项目的可分布性入手，介绍如何使用AP&RP技术。这是一个关于分布式系统设计新手入门的系列文章中的第二篇。您可以点击下面链接找到第一篇文章。
《分布式系统设计新手入门---1，微服务的拆分》
I. 介绍
在新手入门1中我们简要的介绍了AP&RP技术。为了充分展现这个技术带来的惊人效果，我在github.com上随机挑选了一个项目。这个项目是一个电商的开源项目，名称叫shop，作者为Manphil，项目地址为https://github.com/Manphil/shop。这里要向他及其所有开源作者表示感谢。如果没有他们的工作，我将需要耗费更多的时间来编写本章的实例。首先我要对这个项目做一个整体的技术介绍。这是一个使用JAVA语言开发的电商项目。开发环境为开发环境：IDEA、Tomcat8.5。使用的数据库为MySql。分为前端两个部分，前端使用Bootstrap以及JQuery，后端基于SpringMVC、Spring、MyBatis进行开发，使用Maven构建工程。因为我们只是分析服务端系统的可分布性，限于篇幅将略过项目的构建，调试以及前端的部分。虽然这个实例为JAVA语言，但本篇所介绍的技术同样适用于nodejs，C++，C等语言开发的服务端软件系统。
II. 整体的产品功能及系统架构
Shop并不是一个成熟的开源项目，很多功能处于开发过程中。通过对其分析产生了一些让我也感到惊讶的结论。我会在后面总结这些结论。shop项目主要分为两个大部分，第一部分为系统管理，第二部分为前端调用接口。其全部有11个产品功能组成。如图1所示

Shop系统架构也较为简单，分为后端服务和数据库端。后端服务直接通过MyBatis中间件链接数据库。如图2所示

在shop中有62个可以被调用的接口链接。也就是说整个系统是由62个任务所组成的。相对于比较成熟的电商项目有着上百个接口来说，shop是比较简单的。
III. 分析任务1
先假设shop可以通过MySql集群实现AP操作，那么我们只要对软件系统中的任务读写数据的情况进行分类既RP分析，就可以知道项目shop能否进行分布式操作。这里我们挑选shop中比较复杂的两个任务来介绍具体的分析过程。其中之一是/info/list，这个功能负责返回用户的订单信息。他位于shop/controller/front/CustomerController.java文件中。
其源代码如下：

@RequestMapping("/info/list")
    public String list(HttpServletRequest request,Model orderModel){
        HttpSession session=request.getSession();
        User user;
        user=(User)session.getAttribute("user");

        if (user==null)
        {
            return "redirect:/login";
        }

        OrderExample orderExample=new OrderExample();
       orderExample.or().andUseridEqualTo(user.getUserid());
        List<Order> orderList=orderService.selectOrderByExample(orderExample);
        orderModel.addAttribute("orderList",orderList);
        Order order;
        OrderItem orderItem;
        List<OrderItem> orderItemList=new ArrayList<>();
        Goods goods;
        Address address;
       for (Integer i=0;i<orderList.size();i++)
       {
           order=orderList.get(i);
           OrderItemExample orderItemExample=new OrderItemExample();
           orderItemExample.or().andOrderidEqualTo(order.getOrderid());
           orderItemList=orderService.getOrderItemByExample(orderItemExample);
           List<Goods> goodsList=new ArrayList<>();
           List<Integer> goodsIdList=new ArrayList<>();
           for (Integer j=0;j<orderItemList.size();j++)
           {
               orderItem=orderItemList.get(j);
               goodsIdList.add(orderItem.getGoodsid());
           }
           GoodsExample goodsExample=new GoodsExample();
           goodsExample.or().andGoodsidIn(goodsIdList);
           goodsList=goodsService.selectByExample(goodsExample);
           order.setGoodsInfo(goodsList);
           address=addressService.selectByPrimaryKey(order.getAddressid());
           order.setAddress(address);
           orderList.set(i,order);
       }
       orderModel.addAttribute("orderList",orderList);
       return "list";
    }

1, “@RequestMapping("/info/list")”表示uri的链接/info/list将会触发调用函数“public String list(HttpServletRequest request,Model orderModel)”。这个调用并没有传递参数到函数中。它被触发的形式可能为http://localhost/info/list。
2, 在“HttpSession session=request.getSession();”中首先读取了session的数据。Session内保存了当前链接关于安全和权限的数据。这段代码是检验只允许已经登陆的用户才能使用这个接口。注意session中的数据作为全局数据也是我们要分析的数据之一。
3, 在“List orderList=orderService.selectOrderByExample(orderExample);”中读取了指定用户的所有订单的数据。其中“orderService.selectOrderByExample”最终被转换为mysql数据库的查询操作。
4, 在获取了用户全部订单信息后，通过语句“orderItemList=orderService.getOrderItemByExample(orderItemExample);”查询具体订单中的物品信息。
5，在“goodsList=goodsService.selectByExample(goodsExample);”中查询物品的商品信息。
6,　以及在address=addressService.selectByPrimaryKey(order.getAddressid());查询对应订单的地址信息。
以上5个信息分别存储在数据库中的address，indent ，orderitem，goods以及全局数据session中。这里是以整个表为读取数据的使用范围。请注意这里的使用数据的范围。以读取用户全部订单为例，其使用数据的范围为整个indent表。得到的数据是用户的当前订单。这里以使用数据范围为边界而不是以得到的数据范围为边界。通过以上分析我们得到了“/info/list”的使用数据的范围并记录下来。如图3所示

IV. 分析任务2
我以“/orderFinish”来分析有写入数据的情况。“/orderFinish”的功能是将购物车的数据提交为订单。其代码如下

@RequestMapping("/orderFinish")
@ResponseBody
public Msg orderFinish(Float oldPrice, Float newPrice, Boolean isPay, Integer addressid,HttpSession session) {
    User user = (User) session.getAttribute("user");

    //获取订单信息
    ShopCartExample shopCartExample = new ShopCartExample();
    shopCartExample.or().andUseridEqualTo(user.getUserid());
    List<ShopCart> shopCart = shopCartService.selectByExample(shopCartExample);

    //删除购物车
    for (ShopCart cart : shopCart) {
        shopCartService.deleteByKey(new ShopCartKey(cart.getUserid(),cart.getGoodsid()));
    }

    //把订单信息写入数据库
    Order order = new Order(null, user.getUserid(), new Date(), oldPrice, newPrice, isPay, false, false, false, addressid,null,null);
    orderService.insertOrder(order);
    //插入的订单号
    Integer orderId = order.getOrderid();

    //把订单项写入orderitem表中
    for (ShopCart cart : shopCart) {
        orderService.insertOrderItem(new OrderItem(null, orderId, cart.getGoodsid(), cart.getGoodsnum()));
    }

    return Msg.success("购买成功");
}

1, 首先“@RequestMapping("/orderFinish")”将uri映射到了orderFinish函数。并传入了5个参数。这5个参数是前端调用uri时同时传入的。
2, 在第一句中“User user = (User) session.getAttribute("user");”通过session获得了当前用户信息。
3, 在“List shopCart = shopCartService.selectByExample(shopCartExample);”中获得了数据库内的用户购物车信息。
4, 在“shopCartService.deleteByKey(new ShopCartKey(cart.getUserid(),cart.getGoodsid()));”中删除了数据库内的购物车信息。
5, 在“orderService.insertOrder(order);”将购物车的数据转为订单并提交到订单数据库。
6，在“orderService.insertOrderItem”中将订单中的物品提交到了数据库中的“orderitem”数据表。
通过对上述写入和读取数据范围的分析可知。“/orderFinish”读取了shopcart表和“session”中的数据。其读取范围为shopcart表和全部“session”。写入了shopcart，indent ，orderitem共3个数据库中的表。其写入数据的边界同样为这3个表的全部。注意这里是插入数据而不是更新数据。如果是更新数据，其更新的范围会更小。我们将在后续的章节里进一步讨论其中的细微差别。同样将我们的分析结果记录下来如图4所示

V. 工程的可分布性
当我们把所有的任务读取和写入的数据都整理好以后放入表格文件（见附件）。我们发现在这个工程中只有少数操作使用数据库字段。大部分数据都是以表为单位使用全部数据字段。在项目中无效的任务为6个。有读取数据的任务为28个。有写入数据的任务有30个。写入数据之间没有原子关系的任务为1个。有原子关系的任务共29个分为8组。除去无效任务剩余的37组任务可以分布到37个服务器容器中。整体工程的可分布性比率即可分布任务组与有效任务之比为69.3%。如图5所示

其中任务有原子关系是指读取的数据之间有写入冲突只能放在有原子性的服务器容器内。在30个有写入数据的任务中，有29个任务有原子关系共分为8组。例如“/addCategoryResult”，“/saveCate”，“/deleteCate”都写入表category。所以这3个任务具有原子关系，被分为一组。这8组写入任务最多只能放在8个有原子属性的服务器容器内。也就是8个单线程的服务器容器。
对于其余的28个只读任务，在前面已经假定我们使用的是分布式数据库集群来模拟AP技术。这种数据库集群可以使用Oracle, HP vertica, SAP HANA或OceanBase，以上是世界知名公司的产品，不需要我来打广告。虽然使用数据库集群模拟的AP操作效率较低，但为了更方便初学者我们使用数据库集群来替代AP操作，以后的章节里我们会学习如何手动进行AP操作。这里先假定数据库集群可以为每个任务提供一个额外的服务器节点用于处理AP操作。那么这个项目在一般情况下最大可以分布到74台服务器集群中。
VI. 一般分布式方法
让我非常惊讶的事情在于一个电商网站的工程离散性居然如此之高。在没有使用任何其他特殊技术的情况下只是引入了数据库集群。并且没有修改任何代码的情况下就将服务器扩张了74倍。如果按传统的产品功能分割的方法则最多只能分为11个部分。而且要非常耗时耗力的分割软件工程和分割数据库。这里我将这种分布式技术的一般应用称为一般分布式技术。一般分布式技术是在最小改动工程的基础上运用分布式技术进行系统分布式的方法。与此相对而言，AP&RP技术绝不仅仅限于此。在使用一般分布式方法处理后的工程，我们会得到一个关于任务uri影射表的。以此项目为例可以简单的将服务端软件复制37份并放入37个服务器容器内。并使用nginx反向代理将uri影射到不同的服务器容器内。注意这里并不需要你去拆分软件工程。只要让不同的服务器容器处理不同的请求就可以了。例如我们配置其中一个服务器容器192.168.1.1用于处理category表的写入请求。前面得知“/addCategoryResult”，“/saveCate”，“/deleteCate”三个任务会写入category所以添加配置到nginx如下：

location /addCategoryResult {
        proxy_pass http:// 192.168.1.1:8080;
    }
location /saveCate {
        proxy_pass http:// 192.168.1.1:8080;
    }
location /deleteCate {
        proxy_pass http:// 192.168.1.1:8080;
    }

将反向代理和数据库集群以及37个服务器的复制品放在一起，我们得到被分布式后的shop工程。如图6所示

VII. 一些知识点与问题
1， AP&RP技术是否安全可靠？
首先AP&RP技术没有修改您的任何业务逻辑。也没有增加任何额外的业务及硬件层级。所以不存在AP&RP技术失效导致系统停用的问题。在一般分布式技术中，从直观角度说由单台服务器扩张到多台服务器后。其中任何服务器的失效都不会导致集群整体业务的停止。所以这种扩展是对集群安全性的提升。现有的分布式方法是否更加安全呢？建议你去读FLP定理的相关论文。分布式系统不会比硬件带来更多的可靠性。这里向为我们提供了更多可靠性而不断努力的硬件工程师致敬。
2， 谬误1，在不同功能分类中不存在有原子关系的任务。
因为功能分类的划分是主观而随意的。常常会将一些有原子关系的任务划分到不同的功能中。例如示例中活动商品管理中的任务“/update”需要设置“goods(activityId)”与商品管理功能产生了原子关系。将这个任务与其他具有原子关系的任务放在一起，在分割中会更为自然。这里应将“/update”放入到商品管理中，这样做从产品设计的角度就显得有些奇怪。
3， 谬误2，按功能分类不出问题但不代表正确。
目前绝大多数分布式系统都是按功能进行划分的。然后工程师依据是否出现问题去修正系统。虽然大部分按功能划分的系统都运行良好。但我思考这也仅仅是运行良好而以。因为刚好没有触发RP冲突也就是原子关系的冲突。在一定概率上运行良好就认为这样划分没有问题，这是非常危险和不严谨的态度。
4， 过度分层导致心智负担严重。
软件功能过多的分层和硬件系统过多的分层对开发人员导致了严重的心智负担。仅仅为了阅读看起来更有层次而产生的分层。将软件真实处理过程与触发点严重分割开来。导致对软件的阅读产生了极大的障碍。例如本示例从触发数据库操作到真实调用数据库之间要跳转3个文件。而且作者额外开发了大量最终没有使用的数据库调用方法。这都导致了开发效率下降和开发成本增加。
5， 有弹性的分布式系统。
随着软件系统的访问流量的增长，系统拆分的越来越细是必然需求，但随着拆分的越来越细，工程的复杂度也会越来越高。当复杂度超过人脑在有限时间范围内能够理解的程度时，就需要计算机系统有能够按规则自动完成分解系统的能力。显然在处理极度复杂的系统时不能再单纯的依靠人力。因为人力管理本身就是极其不可靠和复杂的。我们需要更有弹性的自动化分布式系统。今后的章节里我们将会讨论更多的技术细节并最终完成一个有弹性的自动化分布式系统。
6， 从面向计算到异步网络的延伸。
分布式这门学科创建之初主要是为了解决数学计算能否分解的难题。例如能否用分布式的方法逆向hash算法。那时计算机还只是作为计算的工具。而此时计算机系统更像是人类社会中某个工具的延伸。你可以当它是商店，停车场收费器，外卖的呼叫器。人类网络本身就是一个大型的异步系统。当这种异步系统延伸到计算机系统时，计算机系统只是延续了人类这个异步系统的高离散性。这种离散性便是能否进行分布式及其边界划分的基础。我们也会花更多的时间来讨论分布式技术在学术上的意义。
VIII. 感谢
首先这里我想感谢我的妻子在我进行学术研究的这一年里对我的支持。更要感谢您抽出宝贵时间进行阅读。希望我的文章能够帮助您学习了解分布式技术，并将AP&RP技术应用到您的网站设计中。现在您就可以动起手来看看您网站的可分布性啦？