关于推进网站集约化建设的讲话,个人博客网站,岳阳网站建设哪里便宜,上海网站制作公司有哪些微服务架构
微服务架构是一种架构概念#xff0c;旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中#xff0c;从而降低系统的耦合性#xff0c;并提供更加灵活的服务支持。
和 微服务 相对应的#xff0c;这…微服务架构
微服务架构是一种架构概念旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中从而降低系统的耦合性并提供更加灵活的服务支持。
和 微服务 相对应的这种方式一般被称为 单体式开发Monolithic。既所有的功能打包在一个 WAR 包里基本没有外部依赖除了容器部署在一个 JavaEE 容器TomcatJBossWebLogic里包含了 DO/DAOServiceUI 等所有逻辑。 单体应用的优缺点 优点
开发简单集中式管理基本不会重复开发功能都在本地没有分布式的管理和调用消耗
缺点
效率低开发都在同一个项目改代码相互等待冲突不断维护难代码功能耦合在一起新人不知道何从下手不灵活构建时间长任何小修改都要重构整个项目耗时稳定性差一个微小的问题都可能导致整个应用挂掉扩展性不够无法满足高并发下的业务需微服务的优缺点 优点
它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务这种架构使得每个服务都可以由一个团队独立专注开发微服务架构模式可以实现每个微服务独立部署微服务架构模式使得每个服务能够独立扩展
缺点挑战
微服务是一个分布式系统其使得整体变得复杂。开发人员需要基于RPC或者消息实现微服务之间的调用和通信而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单因为单体应用往往只存在一个数据库。但在微服务架构下不同服务可能拥有不同的数据库。CAP原理的约束使得我们不得不放弃传统的强一致性而转而追求最终一致性这个对开发人员来说是一个挑战。跨越多服务变更。在单体应用程序中您可以简单地修改相应的模块、整合变更并一次性部署他们。相反在微服务中您需要仔细规划和协调出现的变更至每个服务。部署基于微服务的应用程序也是相当复杂的测试
以上问题和挑战可大体概括为
API Gateway服务间调用服务发现服务容错服务部署数据调用
目前流行的两种微服务框架解决方案可以解决以上问题
SpringBoot SpringCloud SpringBoot是 Spring 的一套快速配置框架可以基于spring boot 快速开发单个微服务Spring Cloud基于Spring Boot为微服务体系开发中的架构问题提供了一整套的解决方案——服务注册与发现服务消费服务保护与熔断网关分布式调用追踪分布式配置管理等路由网关Dubbo ZooKeeper Dubbo是一个阿里巴巴开源出来的一个分布式服务框架致力于提供高性能和透明化的RPC远程服务调用方案以及SOA服务治理方案。ZooKeeper用来实现服务的注册与发现和进行负载均衡
基于微服务架构的应用是分布式系统增加了系统设计和实现的难度主要有以下方面
运行环境中微服务实例的网络地址是动态分配的微服务运行的实例是动态变化的需要一套发现机制使服务调用者可以获取正确的服务地址。服务之间存在着复杂的依赖关系在高并发访问下依赖的稳定性影响系统的可用性及性能因此需要提供容错机制当依赖的服务发生故障时不会使调用方线程被长时间占用不释放避免故障在系统中蔓延。需要一个高效的进程间通信机制支持微服务之间的交互。服务实例的启停及流量的调度和分配需要一套负载监控和负载均衡组件来管理。
微服务架构的基本组件
可持续交付的平台服务注册与发现组件ZooKeeper服务网关
一般微服务在系统内部通常是无状态的用户登入信息和权限管理最好有一个统一的地方维护管理OAuth。类似SSO单点登入 API网关 服务间通信
一般在后台 N 个服务和 UI 之间一般会一个代理或者叫 API Gateway 提供统一服务入口让微服务对前台透明聚合后台的服务节省流量提升性能PC、Android/IOS端只需记住API网关的IPAPI网关会有一个后台服务IP列表提供安全过滤流控等API管理功能其实这个 API Gateway 可以有很多广义的实现办法可以是一个软硬一体的盒子也可以是一个简单的 MVC 框架甚至是一个 Node.js 的服务端所有的微服务都是独立的 Java 进程跑在独立的虚拟机上所以服务间的通信就是 IPCInter Process Communication已经有很多成熟的方案。现在基本最通用的有两种方式 服务间通信
同步调用(阻塞)
服务间通信网络中只有字符串可以穿透防火墙
RESTJAX-RSSpring BootHttp通信
RESTapiString json /users/list;USer user new USer();user.setId(json.getId());
RPCThrift, Dubbo远程过程调用 User user new RPCUser();
同步调用比较简单一致性强但是容易出调用问题性能体验上也会差些特别是调用层次多的时候。一般 REST 基于 HTTP更容易实现更容易被接受服务端实现技术也更灵活些各个语言都能支持同时能跨客户端对客户端没有特殊的要求只要封装了 HTTP 的 SDK 就能调用所以相对使用的广一些。RPC 也有自己的优点传输协议更高效安全更可控特别在一个公司内部如果有统一个的开发规范和统一的服务框架时他的开发效率优势更明显些。就看各自的技术积累实际条件自己的选择了。 对外REST对内RPC
异步消息调用
KafkaNotifyMessageQueue
异步消息的方式在分布式系统中有特别广泛的应用他既能减低调用服务之间的耦合又能成为调用之间的缓冲确保消息积压不会冲垮被调用方同时能保证调用方的服务体验继续干自己该干的活不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱需要接受数据 最终一致性还有就是后台服务一般要实现 幂等性因为消息送出于性能的考虑一般会有重复保证消息的被收到且仅收到一次对性能是很大的考验最后就是必须引入一个独立的 Broker消息队列的中间服务器 服务发现
在微服务架构中一般每一个服务都是有多个拷贝来做负载均衡。一个服务随时可能下线也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知服务如何管理
这就是服务发现的问题了。一般有两类做法也各有优缺点。基本都是通过 Zookeeper 等类似技术做服务注册信息的分布式管理。当服务上线时服务提供者将自己的服务信息注册到 ZK或类似框架并通过心跳维持长链接实时更新链接信息。服务调用者通过 ZK 寻址根据可定制算法找到一个服务还可以将服务信息缓存在本地以提高性能。当服务下线时ZK 会发通知给服务客户端。
ZooKeeper实现了分布式锁解决单点故障问题
服务注册 Dubbo是一个RPC通信框架ZooKeeper服务注册与发现。此处两者结合使用。
基于客户端的服务注册与发现
优点是架构简单扩展灵活只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址有技术难度一般大公司都有成熟的内部框架支持比如 Dubbo。 此处调用可以是Dubbo服务注册为ZooKeeper 基于服务端的服务注册与发现
优点是简单所有服务对于前台调用方透明一般在小公司在云服务上部署的应用采用的比较多。
LB为负载均衡服务器由LB去查询注册中心再去调用对应指定的服务 微服务需要考虑的问题
API Gateway服务间调用服务发现服务容错服务部署数据调用微服务幂等性
分布式系统中的幂等性概念用户对于同一操作发起的一次请求或者多次请求的结果是一致的不会因为多次点击而产生了副作用。
幂等场景
可能会发生重复请求或消费的场景在微服务架构中是随处可见的。
网络波动因网络波动可能会引起重复请求 分布式消息消费任务发布后使用分布式消息服务来进行消费 用户重复操作用户在使用产品时可能无意地触发多笔交易甚至没有响应而有意触发多笔交易 未关闭的重试机制因开发人员、测试人员或运维人员没有检查出来而开启的重试机制如Nginx重试、RPC通信重试或业务层重试等
CRUD操作分析 新增类请求不具备幂等性 查询类动作重复查询不会产生或变更新的数据查询具有天然幂等性 更新类请求 基于主键的计算式Update不具备幂等性即UPDATE goods SET numbernumber-1 WHERE id1基于主键的非计算式Update具备幂等性即UPDATE goods SET numbernewNumber WHERE id1基于条件查询的更新不一定具备幂等性需要根据实际情况进行分析判断删除类请求 基于主键的Delete具备幂等性一般业务层面都是逻辑删除即update操作而基于主键的逻辑删除操作也是具有幂等性的
幂等性的重要性
针对一个微服务架构如果不支持幂等操作那将会出现以下情况
电商超卖现象重复转账、扣款或付款重复增加金币、积分或优惠券
超卖现象 比如某商品的库存为1此时用户1和用户2并发购买该商品用户1提交订单后该商品的库存被修改为0而此时用户2并不知道的情况下提交订单该商品的库存再次被修改为-1这就是超卖现象。
究其深层原因是因为数据库底层的写操作和读操作可以同时进行虽然写操作默认带有隐式锁即对同一数据不能同时进行写操作但是读操作默认是不带锁的所以当用户1去修改库存的时候用户2依然可以都到库存为1所以出现了超卖现象。
解决方案A可以对读操作加上显式锁即在select …语句最后加上for update这样一来用户1在进行读操作时用户2就需要排队等待了。但问题来了如果该商品很热门并发量很高那么效率就会大大的下降如何解决呢(解决方案B)
解决方案B我们可以有条件有选择的在读操作上加锁比如可以对库存做一个判断当库存小于一个量时开始加锁让购买者排队这样一来就解决了超卖现象。
解决方案
全局唯一ID
如果使用全局唯一ID就是根据业务的操作和内容生成一个全局ID在执行操作前先根据这个全局唯一ID是否存在来判断这个操作是否已经执行。如果不存在则把全局ID存储到存储系统中比如数据库、Redis等。如果存在则表示该方法已经执行。
使用全局唯一ID是一个通用方案可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦下面的方案适用于特定的场景但是实现起来比较简单。
去重表
这种方法适用于在业务中有唯一标识的插入场景中比如在以上的支付场景中如果一个订单只会支付一次所以订单ID可以作为唯一标识。这时我们就可以建一张去重表并且把唯一标识作为唯一索引在我们实现时把创建支付单据写入去重表放在一个事务中如果重复创建数据库会抛出唯一约束异常操作就会回滚。
插入或更新
这种方法插入并且有唯一索引的情况比如我们要关联商品品类其中商品的ID和品类的ID可以构成唯一索引并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。
多版本控制
这种方法适合在更新的场景中比如我们要更新商品的名字这时我们就可以在更新的接口中增加一个版本号来做幂等boolean updateGoodsName(int id,String newName,int version);
在实现时可以如下update goods set name#{newName},version#{version} where id#{id} and version${version}
状态机控制
这种方法适合在有状态机流转的情况下比如就会订单的创建和付款订单的付款肯定是在之前这时我们可以通过在设计状态字段时使用int类型并且通过值类型的大小来做幂等比如订单的创建为0付款成功为100付款失败为99。在做状态机更新时我们就这可以这样控制update goods_order set status#{status} where id#{id} and status#{status}
以上就是保证接口幂等性的一些方法。
总结
幂等性设计不能脱离业务来讨论一般情况下去重表同时也是业务数据表而针对分布式的去重ID可以参考以下几种方式
UUIDSnowflake数据库自增ID业务本身的唯一约束业务字段时间戳拼接
分类: 分布式
