- 日志聚合,全链路监控(高度可观察和分析诊断问题)。
说了那么多,那什么样的情况下,你的团队不适合建设微服务?(请勿对号入座)
-
开发团队不具备自主性,所在组织对开发团队限制非常多(具体请参考 康威定律)。
-
团队不熟悉业务,无法识别出服务的边界,进行合理的拆分(请参考 DDD 领域驱动设计)。
微服务设计其实是很早就有的设计思想,因为随着虚拟化技术的崛起,微服务可以低成本的实现,所以也开始流行和兴起。
微服务的内涵很深,其中就包括,自动化,去中心化,独立性等等,其中细节无法用一篇文章概述清楚,我们在做技术选型或者方案的时候,尽可能多去了解技术的本身和起源再结合我们业务的特点,进行更好的选择。
如何低成本的实现微服务?
============
Spring Cloud 为什么是国内最流行的微服务框架,它提供哪些开箱即用的组件 ?
概览如下:
-
Srping Boot 服务应用
-
Spring Cloud Config 配置中心
-
Spring Cloud Eureka 服务发现
-
Spring Cloud Hystrix 熔断保护
-
Spring Cloud Zuul 服务网关
-
Spring Cloud OAuth 2 服务保护
-
Spring Cloud Stream 消息驱动
-
分布式全链路跟踪
-
部署微服务
①Spring Boot 微服务基石
Spring Boot 是构建微服务的理想框架,主要得益于 Spring Boot 可以打包成为单个可执行JAR文件交付服务,Spring Actuator 公开服务健康信息都是微服务的基石,为什么这么说 ?
我们先看看构建微服务的四个重要原则:
-
服务应该是独立和可独立部署的
-
应该从中央(配置中心)读取配置
-
对客户端是透明的
-
传达健康信息
微服务有优点和缺点,并非所有应用都适合用微服务架构,架构师需要能做到以下要求:
-
分解业务问题:描述业务问题,注意动词,寻找数据内聚。
-
建立服务粒度:讲大服务重构到更小的服务,重点关注服务如何相互交互,服务职责随时间改变。
-
定义服务接口:拥抱 REST 的理念,使用 URI 来传达意图,使用 HTTP 状态码传达结果。
糟糕的微服务有哪些特征?
-
过于粗粒度:服务承担过多的职责,服务跨大量表来管理数据,测试用例太多。
-
过于细粒度:服务彼此依赖严重,服务内部没有逻辑。
何时不应该使用微服务 ?
-
不愿投入(需要高度成熟的运维,伸缩,复杂性问题)。
-
管理/监控散乱的服务器也需要很高的成本。
-
小型应用不适合,太昂贵。
-
数据事务(分布式系统处理事务非常困难)
②Spring Cloud Config 配置服务
Spring Config 是 Spring 提供的配置中心轻量级实现,基于 Git 存储,国内用户大多推荐使用 Alibaba 开源的 Nacos(集成配置中心和注册中心)都是非常不错的配置中心的实现。
微服务程序对于配置中心的几点管理原则:
-
应用程序的配置和部署的实际代码分离(配置中心和应用程序分离)。
-
集中(将配置中心集中在少量的存储库中)。
-
稳定(配置中心要保证高可用)。
Spring Config 这款配置中心提供的核心功能:
-
配置服务器允许使用环境特定值。
-
使用 Spring Profile 区分环境值。
-
可以使用基于文件或基于 Git 存储属性。
-
允许对称加密和非对称加密。
③Spring Cloud Eureka 服务发现
服务发现是微服务架构中非常重要的概念,也称注册中心,类似我们生活中的房地产中介的角色,买房卖房都要通过它。
所以它是所有微服务上线/下线的必经之路,也掌握微服务的生杀大权,注册中心会根据 CAP 策略和对微服务的健康检查,作出对具体服务剔除,下线,恢复上线等操作。
主要还有以下几个核心功能:
-
快速对环境中服务数量水平伸缩(功能和 K8s 有些重合,不过也可以设定具体服务的运行时数量)。
-
抽象服务的物理位置(微服务通常运行在 Docker 容器内,没有固定 IP,只能通过注册中心才能找到它)。
-
提高程序的弹性,自动伸缩。
-
信息共享, 健康检测。
微服务架构里面要实现注册中心,需要达到哪些基本要求?
-
高可用,注册信息共享(注册中心集群部署),不可能因为注册中心挂了,导致所有集群不可用。
-
负载均衡(对服务间的动态请求负载均衡),合理在服务间分配流量。
-
有弹性(客户端缓存服务信息)。
-
容错,健康检查(检测坏掉的服务自动移除,无需人工干预)。
Spring Eureka 提供的服务发现实现,具备哪些特点 ?
-
服务发现抽象服务的物理位置。
-
无感知添加和移除服务。
-
为服务间调用提供负载均衡。
-
使用 3 种不同机制来调用服务:DiscoveryClient,支持 Ribbon 的 RestTemplate,Netflix 的 FeignClient。
④Spring Cloud Hystrix 熔断保护
为什么微服务进行熔断 ?当一个服务出现问题:
-
通常都是从小部分开始,到耗尽线程彻底崩溃。
-
服务间调用会长时间阻塞。
-
服务未关闭就会一直被调用,导致连锁效应。
-
一个性能不佳的服务可以迅速拖垮整个应用。
为什么熔断很重要 ?
-
每个节点(调用服务和数据库)实现断路器,可以避免服务崩溃的连锁效应。
-
实现只有出问题的服务受影响,其余的服务功能都是完整的(影响范围降到最小)。
-
熔断是服务器的灵活的基础。
断路器提供的关键能力:
-
快速失败。
-
功能降级(替代方案)。
-
无缝恢复(断路器定期检查,自动恢复服务)。
Netflix 研发和出品的 Hystrix 实现是一款成熟稳定的熔断实现,在 Netflix 在生产实践和运行多年,非常可靠,后面加入 Spring Cloud 体系,成为 Spring Cloud 微服务生态链的一员,使用起来也非常的简单和方便。
Hystrix 支持四种断路模式:
-
客户端负载均衡模式(检测服务出错,移除服务)。
-
断路器模式(出现超时抛出异常强行失败,超过阈值强行失败所有调用)。
-
后备模式(不是抛出异常而是执行替代方案,例如排队,稍后再试等)。
-
舱壁模式(把远程调用的资源分配到独立的线程池中,调用出问题只是线程池饱和并停止请求)。
跳闸会导致的三种结果:
-
服务 B 立即知道服务 C 有问题,不必等待,立即失败。
-
服务 B 执行服务 C 的替代代码来采取行动(后备模式)。
-
服务 C 可以在跳闸后,检查问题,快速恢复。
熔断的几个处理原则:
-
设计分布式应用必须考虑弹性。
-
服务的彻底故障是很容易检测和处理,只是需要时间,断路器给了这个时间窗口。
-
一个服务性能不佳,可能导致集群崩溃,因为相互调用会阻塞线程,耗尽资源。
-
Hystrix 支持两种隔离模型,即 THREAD 和 SEMAPHORE。
⑤Spring Cloud Zuul 网关
网关是整个微服务分布式集群的入口,对于用户来说,用户无需知道你每个服务的地址,只需要记住网关地址就可以了。
这样理解可能比较抽象,举一个生活的例子,微服务集群是一个大型公司,公司内部有很多个不同的职能部门(对应每个微服务)。
但是你如果要访问具体的职能部门,你必须先到前台登记,再由前台带你到你想访问的具体职能部门去办理实际的业务(智能路由)。
微服务对于网关实现的规范:
-
一个独立负责所有服务调用过滤和路由的服务。
-
服务和客户端的中间人,简化客户端开发。
网关通常要做哪些事情:
-
静态路由,从注册中心获取每个微服务的具体位置。
-
动态路由(根据参数特点,调用特定服务,少量用户体验新功能,通常用于灰度发布)。
-
验证和授权:验证访客的身份信息(统一验证,服务只需要关注业务逻辑)。
-
数据收集和日志(收集调用次数和响应时间等)。
Zuul 网关的具体运行参考图:
Spring Cloud Zuul 是初期版本的 API 网关实现,提供以下功能:
-
结合 Spring Cloud Eureka 将服务发现的注册地址加入到 Zuul 路由。
-
Zuul 可以给所有服务轻松的添加/API 之类的前缀路由地址。
-
在全局上定制 Zuul 的 Spring Cloud Hystrix 和 Spring Cloud Ribbon (调度策略)的超时。
-
实现动态路由,不同版本进行 A/B 测试。
-
检查参数合法性等,例如 JWT,时间戳等等。
⑥Spring Cloud OAuth 2 服务保护
Oauth 2 是用于保证请求的合法和正确性,为了让微服务本身更加专注于业务,所以 OAuth 2 类似配置中心被单独抽离出来作为基础组件的统一认证中心来使用。
OAuth 2 的作用类似我们生活中的公安局的角色,当我们需要去正规机构办理业务的时候,我们需要提供有效的身份证(合法的身份认证标示)。
如果没有你就需要去公安局(OAuth)申请一张在有效期内的身份证(Token),然后带着这张身份证我们才能去购买机票,酒店等其他社会服务(微服务)。
社会服务机构在拿到你提供的身份证(Token)后,也会向公安局(OAuth)联网发送信息,来验证你的身份证的合法性(Token 合法性校验),身份认证不通过就会被拒绝服务,合法的身份才能进行业务的办理。
关于 OAuth 的工作流程,可以结合下图来理解:
微服务对于 OAuth2 规范的 4 种类型授权:密码/客户端凭据/授权码/隐式。
Spring Cloud OAuth 2 为我们提供哪些便利?
-
安全框架,提供令牌生成,验证等逻辑。
-
开箱即用,和其他服务无缝集成。
-
行业标准,轻松与云服务商集成。
OAuth 2:/auth/oauth/token 的返回信息:
-
access_token(OAuth 2 令牌,每次调用出示)。
-
token_type(令牌类型,常用 bearer token)。
-
refresh_token(续约令牌)。
-
expires_in(过期描述,默认 12H)。
-
scope(令牌有效作用域)。
OAuth 2 支持 JWT (JSON Web Token)的规范,关于 JWT 的原理就不特别解释了。
简单的 JWT 有以下几个特点:
-
小巧(Base64编码)。
-
密码签名(防篡改)。
-
自包含(不需要调用验证服务确认内容,通过相同的密钥进行对称解密)。
-
可扩展(可在令牌内包含额外的信息)。
小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
最后
由于篇幅限制,小编在此截出几张知识讲解的图解
…(img-1iS4mJFw-1710423855817)]
[外链图片转存中…(img-3LGf0SCy-1710423855818)]
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
[外链图片转存中…(img-K53pV0gG-1710423855819)]
最后
由于篇幅限制,小编在此截出几张知识讲解的图解
[外链图片转存中…(img-Z0cyhCz9-1710423855819)]
[外链图片转存中…(img-zaQy6fLZ-1710423855820)]
[外链图片转存中…(img-yGyTkSHb-1710423855820)]
[外链图片转存中…(img-tomBXmvd-1710423855820)]
[外链图片转存中…(img-hwJHv3X8-1710423855821)]