微服务架构设计之聚合模式和代理模式
分布式和微服务的关系1、微服务概念
微服务架构是⼀种架构风格与设计模式，具有如下优点：⼩⽽专，提倡将⼤的应⽤分割成⼀系列⼩的服务；⾼内聚，每个服务专注于各⾃单⼀的业务功能；独⽴运⾏，每个服务运⾏于独⽴的进程中，有清晰的服务边界；轻量级通讯，采⽤轻量级的通讯机制（Http/Rest）来实现互通、协作。
⼩⽽专，提倡将⼤的应⽤分割成⼀系列⼩的服务。⽐如将电商平台⼀个单体应⽤拆分成购物、交易、物流、商品，跨功能开发团队（特性团队）负责各⾃模块从需求、UI、设计、实施、运维全过程，快速交付⽤户价值。
⾼内聚，每个服务专注于各⾃单⼀的业务功能。交易服务就只聚焦交易相关业务，订单管理和⽀付管理等。
独⽴运⾏，每个服务运⾏于独⽴的进程中，有清晰的服务边界。
轻量级通讯，采⽤轻量级的通讯机制（Http/Rest）来实现互通、协作。应⽤之间采⽤这种轻量级的通讯机制，使这些应⽤可以采⽤不同的编程语⾔、数据存储技术等进⾏开发，将其集中管理程度降到最低。另外RESTful通讯是⽆状态HTTP协议，扩展能⼒很强。同时传输内容JSON形式序列化，轻量简单，⼈与机器均可读，学习成本低。
2、微服务设计
微服务通常将每个功能都分割成⼀个⼀个服务，然后在分布式集中按需进⾏横向扩展。单体应⽤将所有功能都放到⼀个系统中，并且只能通过整体复制的⽅式进⾏横向扩展。这是单体应⽤和微服务模式的⼀个主要不同点。
微服务化可以借助SpringCloud组件解决单体应⽤难以解决的问题。例如SpringCloud组件中的zuul⽹关可以对请求进⾏鉴权、限流，灰度发布，权限控制、路由、监控等功能；Hystrix可以对服务进⾏熔断、降级处理。就⽐如说有⼀个热点新闻出现了，系统会推荐给⽤户查看新闻详情，然后⽤户会通过id去查询新闻，但是因为这条新闻太⽕，⼤量⽤户同时访问可能会导致系统崩溃，那么我们就进⾏服务降级，部分服务直接提⽰“当前⼈数太多请稍后查看”等。
2.1、采⽤聚合模式的微服务架构
采⽤聚合模式的微服务架构
聚合模式是使⽤最⼴泛的⼀种设计模式，其中聚合层（聚合服务）绘制界⾯和接收⽤户请求，后⾯的原⼦服务层（服务A/B/C）处理⽤户请求，进⾏具体业务逻辑处理。
这种微服务架构模式，往往会涉及到去中⼼化数据管理，像数据库表怎么拆分，拆分后数据表怎么关联查询等。这种模式的架构，数据库通常按照业务进⾏纵向切分，并且遵循⼀定原则的：
1）避免跨库的事务处理
当然事务不跨库是最好的，但微服务中分布式事务是不可避免的，对分布式事务处理也有⽐较成熟的解决⽅案：
两阶段提交，顾名思义两阶段提交就是把事务处理分两个阶段，第⼀阶段只操作不提交，某个操作失败进⾏回滚，都操作成功进⾏第⼆阶段提交操作。
另外⼀个成熟的解决⽅案，事务补偿TCC⽅案，在这个⽅案中需要借助事务协调器，业务应⽤（聚合层服务）在事务协调器中注册⼀个事务，然后业务应⽤直接调⽤各原⼦服务Try接⼝，根据返回结果进⾏提交或回滚操作，各原⼦服务Try接⼝均返回成功，向事务协调器提交事务，之后事务协调器完成Confirm接⼝和Cancel接⼝的操作，之后的Confirm接⼝和Cancel接⼝的操作都由事务协调器完成；Co
nfirm接⼝和Cancel接⼝采⽤事务补偿机制，将之前失败的事务进⾏反向操作，来对事务进⾏补偿；采⽤TCC⽅案不能保证执⾏过程中数据⼀致性，但能保证最终⼀致性。
2）避免库间的表关联查询
以订单查询/客户查询/供应商查询为例，⾸先分页查询出订单信息，然后查询客户信息和供应商信息（rest⼀次获取），最后对订单信息进⾏补填，这样就可以避免库间的表关联查询；读写分离机制，⽣产库中进⾏实时性读写操作，在查询库上进⾏查询操作，⽣产库向查询库上同步数据时，把join操作放到查询库的⼀张表上，从⽽在查询库上查询可以达到秒级。
3）改变原来的查询⽅
2.2、采⽤代理模式的微服务架构
采⽤代理模式的微服务架构
采⽤代理模式的微服务架构，可以看做聚合模式的⼀个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调⽤不同的微服务。代理可以仅仅委派请求，也可以进⾏数据转换⼯作。
2.3、完整的微服务架构
完整的微服务架构
上图为聚合模式的⽐较完整的微服务架构，其中可以清楚看到SpringCloud组件在微服务架构中充当的不同⾓⾊。最外层对外提供服务的是服务⽹关Zuul，提供路由功能、过滤功能、权限验证等功能；最底层为原⼦服务层，它进⾏具体业务逻辑处理；聚合层聚合服务，它主要作
⽤是绘制界⾯和接收⽤户请求；管理中⼼包括注册中⼼Eureka和配置中⼼Config，或是使⽤阿⾥巴巴Nacos。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。