微服务系统实战
文章平均质量分 93
微服务系统实战
庄小焱
我是庄小焱,阿里巴巴Java高级工程师、PMP项目管理专家、系统架构设计师(高级)、CSDN博文专家。 博主在微服务、虚拟化、系统架构、大数据、机器学习领域不断学习,同时在博客中分享自己学习知识和相关技术, 欢迎大家和我交流学习,欢迎大家关注我的博客。
展开
-
微服务系统设计(10)——分布式定时服务设计
用户通过绑定手机号的注册为会员,并可以补充完个人信息,比如姓名、生日等信息,拿到用户的生日信息之后,就可以通过会员生日信息进行营销,此处就涉及到定时任务执行营销信息推送的问题。本篇就带你走入微服务下的定时任务的构建问题。常见的定时任务的解决方案有以下几种:右半部分基于 Java 或 Spring 框架即可支持定时任务的开发运行,左侧部分需要引入第三方框架支持。针对不同方案,作个简单介绍:引入第三方分布式框架会增加项目复杂度,Timer、TimerTask 比较简单无法符合复杂的分布式定时任务,本次选择基于原创 2022-06-24 16:16:01 · 1431 阅读 · 0 评论 -
微服务系统设计(06)——服务注册与发现和配置设计
大型系统中的都是众多服务相互调用来完成某一项功能,这其中就会涉及到是服务的相互调用和发现功能。本博文主要介绍的服务注册与发现设计。在分析业务需求时,其中有个简单的功能点:会员可以开通月卡,开通月卡的同时,需要增加相应的积分。开通月卡功能在会员服务模块维护,但增加积分功能在积分服务模块维护,这就涉及到两个模块间的服务调用问题。单实例情况:可以采用点对点的 HTTP 直接调用,采用 IP + Port + 接口的形式进行。也可以对外暴露 WebService 服务供外部模块调用,但 WebService 的形式原创 2022-06-24 13:47:14 · 360 阅读 · 0 评论 -
微服务系统设计(11)——消息缓存服务设计
缓存与队列,是应对互联网高并发高负载环境的常见策略,缓存极大地将数据读写,队列有效地将压力进行削峰平谷,降低系统的负载。实现队列较好的解决方案就是利用消息中间件,但消息中间件绝不止队列这一个特性,还可以应用于异步解耦、消息驱动开发等功能,本博文介绍微服务下的消息驱动开发。消息中间件产品不可谓不多,常见的有 Apache ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Apache RocketMQ 等等,还有很多,具体如何选型,网络中存在大量的文章介绍(这里有一篇官方的文档,与 ActiveM原创 2022-06-24 16:30:59 · 392 阅读 · 0 评论 -
微服务系统设计(07)——微服务远程调用设计
已经引入 Nacos 基础组件,完成了服务注册与发现机制,可以将所有服务统一的管理配置起来,方便服务间调用。本篇将结合需求点,进行服务间调用,完成功能开发。服务间调用常见的两种方式:RPC 与 HTTP,RPC 全称 Remote Produce Call 远程过程调用,速度快,效率高,早期的 WebService 接口,现在热门的 Dubbo、gRPC 、Thrift、Motan 等,都是 RPC 的典型代表,有兴趣的小伙伴可以查找相关的资料,深入了解下。HTTP 协议(HyperText Transfe原创 2022-06-24 14:14:33 · 531 阅读 · 0 评论 -
微服务系统设计(03)——系统微子服务项目构建设计
经过前期的需求分析和模型设计与系统架构设计,我们对项目的整体结构有了更清晰的认识,剩下的工作就是依据设计,将项目骨架拉出来,往里面直充血肉。构建起系统中的子微服务模块。约定项目名称为 parking-project ,建立 Maven 项目,packaging 方式 为 pom,用于管理所有模块。在 parking-project 项目下依据功能模块依次建立 maven module 子项目。采用 IDE工具。以 Maven Project 形式创建父项目,用于管理子模块功能。.........原创 2022-06-24 11:10:06 · 475 阅读 · 0 评论 -
微服务系统设计(02)——数据模型与系统架构设计
经过前面需求梳理,商场停车收费业务需求情况已经十分明了,本节就依据前文的输出做为输入,开始系统设计工作,包括功能模块设计、存储设计、架构设计等,为后面的编码提供良好的基础保障。基于以上业务情况,按领域划分为七个小模块,每个模块中划分出相应实体、事件,通过软件简略画出关键数据实体-联系图(未包含所有实体),如下图所示:据第一篇需求分析的情况,我们已经识别出关键流程、主要业务模块以及模块中主要的业务实体、实体相关的事件。本案例完全可以采用单实体的模式开发,但为了模拟微服务开发的场景,所以这里按照微服务的设计方式原创 2022-06-23 16:09:39 · 765 阅读 · 1 评论 -
微服务系统设计(09)——分布式缓存服务设计
前面都是在会员与积分模块的业务功能,引领大家尝试了服务维护、配置中心、断路器、服务调用等常见的功能点。本博文节开始进入核心业务模块——停车计费,有两块数据曝光率特别高:进场前的可用车位数和计费规则,几乎每辆车都进出场都用到,这部分俗称为热数据:经常会用到。读关系库很明显不是最优解,引入缓存才是王道。这里仅讨论软件服务端的缓存,不涉及硬件部分。缓存作为互联网分布式开发两大杀器之一(另一个是消息队列),应用场景相当广泛,遇到高并发、高性能的案例,几乎都能看到缓存的身影。从应用与缓存的结合角度来区分可以分为本地缓原创 2022-06-24 15:56:57 · 476 阅读 · 0 评论 -
微服务系统设计(13)——统一鉴权服务设计
商场停车场景中,除了极少数功能不需要用户登陆外(如可用车位数),其余都是需要用户在会话状态下才能正常使用的功能。要在网关层实现统一的认证操作,本博文介绍网关层增加一个公共鉴权功能,来实现简单的认证,采用轻量级解决方案 JWT 的方式来完成。JSON Web Token(缩写 JWT)是比较流行的轻量级跨域认证解决方案,Tomcat 的 Session 方式不太适应分布式环境中,多实例多应用的场景。JWT 按一定规则生成并解析,无须存储,仅这一点要完爆 Session 的存储方式,更何况 Session 在多原创 2022-06-24 18:07:14 · 1616 阅读 · 2 评论 -
微服务系统设计(15)——分布式锁服务设计
对于分布式项目来说分布式锁是一个中高级工程师的必备技能。在停车系统中的会员办理月卡或签到累积的积分,可以在指定时间段内兑换商场优惠券,由于数量有限,时间有限,兑换操作相当集中,如果按正常流程处理的话,肯定会出现超兑的情况。比如只有 5000 张券,结果兑换出 8000 张,这对商场来说是一笔经济损失。为防止超兑,自然做法是按总量一个接一个兑换,至到兑换完,但多并发的情况下如何保证还一个一个兑换呢?自然而然就会想到锁上面来。提及锁,你脑海是不是出现了一堆关于锁的场景:死锁、互斥锁、乐观锁、悲观锁等等,本节介绍原创 2022-06-24 23:17:44 · 453 阅读 · 0 评论 -
微服务系统设计(01)——商场停车系统需求分析
不管是传统开发模式还是时下推崇的敏捷开发模式,都要从源头——业务需求开始着手,缺少了需求获取分析环节或本环节做的不够好,由此造成的错误会随着软件迭代的步伐,逐步被放大,近而造成巨大的损失。有时金钱成本尚可接受,但由此造成的时间成本、机会成本则是无法估量的。选取"商场停车业务"作为需求原型,有两个考量:一是场景熟知度比较高,业务理解上不存在很大障碍;二是能将我们所要表达的微服务特性融入进去,业务复杂度较低,便于上手开发,门槛太高反而不利于技术实践。相信大家经常去商场购物,不管你有没有停过车,商场的停车场不会是原创 2022-06-23 10:45:46 · 679 阅读 · 0 评论 -
微服务系统设计(17)——服务链路跟踪设计
微服务体系下,一个请求会调用多个服务,整个请求就会形成一个调用链,普通的日志输出是无法将整个体系串联起来,调用过程中某一个节点出现异常,定位排查难度系数增高,这种情况下就需要一个组件,来分析系统性能、展现调用链路,以便出现故障时快速定位并解决问题,由此 APM 工具闪亮登场。全称是Application Performance Management,关注于系统内部执行、系统间调用的性能瓶颈分析,与传统监控软件(比如 Zabbix)只提供一些零散的监控点和指标相比,即便告警也不知道问题是出在哪里。抛开商业工具原创 2022-06-24 23:57:48 · 497 阅读 · 0 评论 -
微服务系统设计(16)——微服务监控系统设计
各个微服务模块基本已经就位,但系统运行的情况是怎么样,有没有办法查看的到呢?本篇就带你一起看看如何查看系统运行时的一些信息。帮助开发工程师排序问题,同时也是运维工程师提供数据的监控和服务的保护。本博文将介绍的微服务的监控功能设计。细心的小伙伴发现了,每个微服务的 pom 文件配置中都有如下的 jar 引用,这是 Spring Boot 提供的一系列额外特性组件以帮助你监控管理运行中的系统应用。除了需要引入对应 jar 包外,还需要指定的配置。由于默认只开放了 health、info 两个 API,其它原创 2022-06-24 23:31:01 · 934 阅读 · 0 评论 -
微服务系统设计(08)——服务熔断和降级设计
OpenFeign 完成了微服务间的调用,并且在多实例集群的情况下,通过调整负载策略很好应对并发调用。网络产品开发时,网络有时可能是不可用的,服务亦有可能是不可用的,当调用服务响应慢或不可用时,大量的请求积压,会成为压倒系统骆驼的最后一根稻草。它是分布式系统提供的一个低时延容错机制的基础组件,提供限流、服务降级、系统熔断保护、快速失败等多个维度来保障微服务的稳定性。Hystrix 也是 Netflix 套件的一部分。遗憾的是 1.5.18 版本之后进入了维护模式,官方提供了替代方案:resilience4j原创 2022-06-24 15:35:32 · 397 阅读 · 0 评论 -
微服务系统设计(05)——Spring微服务技术选型设计
微服务设计中的两个重要的项目:Spring Cloud 及Spring Cloud Alibaba,我们需要从理论角度作个整体性掌握,后续进入开发实战作好铺垫工作。为后续的微服务工具的选择和开发选择好的相关的准备。本博文将详细的介绍的Spring Cloud 及Spring Cloud Alibaba的微服务设计。它是由很多个组件共同组成的一套微服务技术体系解决方案,目前最新版本是 Hoxton,它的版本并不是我们常见的大版本、小版本的数字形式,Spring Cloud 的版本规划是按伦敦地铁站的名称先后顺原创 2022-06-24 13:18:22 · 480 阅读 · 0 评论 -
微服务系统设计(04)——接口文档管理设计
整个系统是多个应用一起构建,由于服务不会单独存在,服务开发团队必然与其他服务团队进行服务调用,暴露出对外接口势在必行。早期做开发的时候,大家习惯于以 word 或 excel 的形式,但弊端显而易见,一旦接口发生变动,文档需要同步更新,遗憾的是很多接口已经更新,但文档都没有跟上,相信你也有过痛苦的经历。本文带领你认识几款接口文档管理工具,并实现本案例实践中用到的在线接口文档管理。我们迫切需要一个接口文档工具,能实时与系统接口保持同步,无须额外付出成本(资金成本、时间成本)最好。这里介绍几个开源的 API 工原创 2022-06-24 12:44:49 · 1574 阅读 · 3 评论 -
微服务系统设计(14)——分布式事务服务设计
系统中的某些涉及多服务调用过程中多个数据库写入操作,可能涉及到数据的读写和多服务的数据分读写等……,通常spring中通过 @Transactional 注解进行事务控制,服务内尚未保证数据的完整性,跨服务后数据的完整性无法得到保护。利用分布式事务可以解决这类问题,本博文使用 Seata 组件来进行来确保跨服务场景下的数据完整性问题。先拿一个关键场景来铺垫下主题。车辆交费离场后,主要业务逻辑如下:涉及到三个服务间协作,数据分别写入三个存储库,是一个典型的分布式事务数据一致性问题。来看下正常场景的代码逻辑:原创 2022-06-24 18:05:14 · 314 阅读 · 0 评论 -
微服务系统设计(12)——API 网关服务设计
由于服务粒度的不同以及数据包装因端而异的差异需求,由于的系统采用的是的前后端分离的结构。调用端可以直接调用 BFF 层,由 BFF 层再将请求分发至不同微服务,进行数据组装。由于很多子服务都需要用户验证、权限验证、流量控制等,真的要在每个子服务中重复编写用户验证的逻辑吗?在大型微服务设计时候都在网关层统一处理这些共性需求。如果没有网关的情况下,服务调用面临的几个直接问题:现有系统的调用结构如下图所示:直接由前端发起调用,服务间的调用可以 由服务注册中心调配,但前端调用起来就没这么简单了,特别是后端服务以多实原创 2022-06-24 17:23:00 · 950 阅读 · 0 评论