分布式系统设计新手入门---2,微服务架构中拆分的实践

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 分布式系统设计新手入门---2,微服务架构中拆分的实践引言在这篇文章中将从分析一个开源项目的可分布性入手,介绍如何使用AP&RP技术。这是一个关于分布式系统设计新手入门的系列文章中的第二篇。您可以点击下面链接找到第一篇文章。

分布式系统设计新手入门---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所示
fig1

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

在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个信息分别存储在数据库中的addressindentorderitemgoods以及全局数据session中。这里是以整个表为读取数据的使用范围。请注意这里的使用数据的范围。以读取用户全部订单为例,其使用数据的范围为整个indent表。得到的数据是用户的当前订单。这里以使用数据范围为边界而不是以得到的数据范围为边界。通过以上分析我们得到了“/info/list”的使用数据的范围并记录下来。如图3所示
fig3

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”。写入了shopcartindentorderitem共3个数据库中的表。其写入数据的边界同样为这3个表的全部。注意这里是插入数据而不是更新数据。如果是更新数据,其更新的范围会更小。我们将在后续的章节里进一步讨论其中的细微差别。同样将我们的分析结果记录下来如图4所示
fig4

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

其中任务有原子关系是指读取的数据之间有写入冲突只能放在有原子性的服务器容器内。在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所示
fig6

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技术应用到您的网站设计中。现在您就可以动起手来看看您网站的可分布性啦?

相关文章
|
8天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
14 0
|
6天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。
|
20小时前
|
监控 JavaScript 安全
构建微服务架构下的API网关
【4月更文挑战第15天】在微服务架构中,API网关扮演着至关重要的角色。它作为系统的唯一入口,不仅负责请求的路由、负载均衡和认证授权,还涉及到监控、日志记录和服务熔断等关键功能。本文将探讨如何构建一个高效且可靠的API网关,涵盖其设计原则、核心组件以及实现策略,旨在为后端开发人员提供一套实用的指导方案。
14 4
|
1天前
|
监控 负载均衡 API
构建高性能微服务架构:后端开发的最佳实践
【4月更文挑战第14天】 在当今快速发展的软件开发领域,微服务架构已成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了后端开发人员在设计和维护高性能微服务时需要遵循的一系列最佳实践。我们将从服务划分原则、容器化部署、API网关使用、负载均衡、服务监控与故障恢复等方面展开讨论,并结合实际案例分析如何优化微服务性能及可靠性。通过本文的阅读,读者将获得实施高效微服务架构的实用知识与策略。
|
2天前
|
Kubernetes 监控 Cloud Native
构建高效云原生应用:基于Kubernetes的微服务治理实践
【4月更文挑战第13天】 在当今数字化转型的浪潮中,企业纷纷将目光投向了云原生技术以支持其业务敏捷性和可扩展性。本文深入探讨了利用Kubernetes作为容器编排平台,实现微服务架构的有效治理,旨在为开发者和运维团队提供一套优化策略,以确保云原生应用的高性能和稳定性。通过分析微服务设计原则、Kubernetes的核心组件以及实际案例,本文揭示了在多变的业务需求下,如何确保系统的高可用性、弹性和安全性。
10 4
|
3天前
|
Linux 数据安全/隐私保护
Linux基础与服务器架构综合小实践
【4月更文挑战第9天】Linux基础与服务器架构综合小实践
284 6
|
3天前
|
运维 监控 自动驾驶
构建可扩展的应用程序:Apollo与微服务架构的完美结合
构建可扩展的应用程序:Apollo与微服务架构的完美结合
27 10
|
22天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。
|
22天前
|
监控 持续交付 API
构建高效可扩展的微服务架构
在当今快速迭代和竞争激烈的软件市场中,构建一个高效、可扩展且易于维护的后端系统变得尤为重要。微服务架构作为一种流行的分布式系统设计方式,允许开发者将应用程序划分为一系列小型、自治的服务,每个服务负责执行特定的业务功能。本文将探讨如何利用现代技术栈搭建一个符合这些要求的微服务架构,并讨论其潜在的挑战与解决方案。我们将涵盖服务划分策略、容器化、服务发现、API网关、持续集成/持续部署(CI/CD)以及监控和日志管理等关键主题,以帮助读者构建出既可靠又灵活的后端系统。
|
17天前
|
存储 监控 Kubernetes
探索微服务架构下的系统监控策略
在当今软件开发领域,微服务架构因其灵活性、可扩展性和容错性而日益受到青睐。然而,这种架构的复杂性也为系统监控带来了新的挑战。本文旨在探讨在微服务环境下实现有效系统监控的策略,以及如何利用这些策略来确保系统的健壮性和性能。我们将从监控的关键指标入手,讨论分布式追踪的重要性,并分析不同的监控工具和技术如何协同工作以提供全面的系统视图。