综合来看,其优缺点如下:
-
**优点:**模块的强边界;独立部署;技术选型的多样性。
-
**缺点:**分布式带来编程复杂度,远程调用的消耗;舍弃强一致性,实现最终一致性;操作复杂性要求有一个成熟的运维团队或者运维基础设施。
为什么要采用微服务
是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,但是随之而来的就是引入了微服务本身的复杂度。
需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案,但是仍然是有不小的成本的。
生产力和复杂度的关系如图所示,可见系统越复杂,微服务带来的收益越大。此外,无论是单体应用还是微服务,团队的技能都需要能够把控住。
**马丁·福勒的一个观点是:**除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署),否则都不要考虑微服务。
大部分应用都应该选择单体架构,做好单体应用的模块化而不是拆分成服务。
因此,系统一开始采用单体架构,做好模块化,之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰,再重构为微服务架构是一个合理的架构演化路径。
四个可以考虑上微服务的情况:
-
多人开发一个模块/项目,提交代码频繁出现大量冲突。
-
模块间严重耦合,互相依赖,每次变动需要牵扯多个团队,单次上线需求太多,风险大。
-
主要业务和次要业务耦合,横向扩展流程复杂。
-
熔断降级全靠 if-else。
微服务的三个阶段:
-
**微服务 1.0:**仅使用注册发现,基于 Spring Cloud 或者 Dubbo 进行开发。
-
**微服务 2.0:**使用了熔断、限流、降级等服务治理策略,并配备完整服务工具和平台。
-
**微服务 3.0:**Service Mesh 将服务治理作为通用组件,下沉到平台层实现,应用层仅仅关注业务逻辑,平台层可以根据业务监控自动调度和参数调整,实现 AIOps 和智能调度。
微服务架构
先决条件
微服务的先决条件如下:
-
**快速的环境提供能力:**依赖于云计算、容器技术,快速交付环境。
-
**基本的监控能力:**包括基础的技术监控和业务监控。
-
**快速的应用部署能力:**需要部署管道提供快速的部署能力。
-
**Devops 文化:**需要具有良好的持续交付能力,包括全链路追踪、快速环境提供和部署等,还需要快速的反应能力(对问题、故障的快速响应),开发和运维的协同工作。
此外,根据康威定律和逆康威定律(技术架构倒逼组织架构改进),组织架构也是一个很关键的因素。
对应于微服务架构,组织架构需要遵循以下原则:
-
一个微服务由一个团队维护,团队成员以三人为宜。
-
单个团队的任务和发展是独立的,不受其他因素影响。
-
团队是功能齐全、全栈、自治的,扁平、自我管理。
基础设施
微服务的推行需要依赖于很多底层基础设施,包括提供微服务的编译、集成、打包、部署、配置等工作,采用 PaaS 平台解决微服务从开发到运行的全生命周期管理,同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。
①最基本的基础设施
**进程间通讯机制:**微服务是独立进程的,需要确定之间的通讯方式。
**服务发现+服务路由:**提供服务注册中心,服务提供者和消费者通过服务发现获取服务的信息从而调用服务,实现服务的负载均衡等。
**服务容错:**微服务架构中,由于服务非常多,往往是一个服务挂了,整个请求链路的服务都受到影响。
因此需要服务容错,在服务调用失败的时候能够处理错误或者快速失败,包括熔断、Fallback、重试、流控和服务隔离等。
**分布式事务支持:**随着业务拆分为服务,那么有时候不开避免的就是跨服务的事务,即分布式事务的问题。
原则是尽量避免分布式事务,如果无法避免那么可以使用消息系统或者 CQRS 和 Event Sourcing 方案来实现最终一致性。
如果需要强一致性,则有两阶段提交、三阶段提交、TCC 等分布式事务解决方案。
②提升外部服务对接效率和内部开发效率
**API 网关:**负责外部系统的访问,跨横切面的公共层面的工作,包括安全、日志、权限控制、传输加密、请求转发、流量控制等。
典型的网关功能即对外暴露一个域名 xx.com,根据第一级目录做反向路由 xx.com/user,xx.com/trade。
每一级目录,如 user、trade 对应一个服务的域名。此外,API 网关也可以有服务编排的功能(不推荐)。
**接口框架:**规范服务之间通讯使用的数据格式、解析包、自解释文档,便于服务使用方快速上手等。
③提升测试和运维效率
配置中心: 运行时配置管理能够解决动态修改配置并批量生效的问题。包括配置版本管理、配置项管理、节点管理、配置同步等。
**持续交付:**包括持续集成、自动化部署等流程。目的就是小步迭代,快速交付。
**持续集成:**这一部分并非是微服务特定的,对于之前的单体应用,此部分一般来说也是必要的。
主要是指通过自动化手段,持续地对代码进程编译构建、自动化测试,以得到快速有效的质量反馈,从而保证代码的顺利交付。
自动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接口测试。
**自动化部署:**微服务架构,节点数动辄上百上千,自动化部署能够提高部署速度和部署频率,从而保证持续交付。
包括版本管理、资源管理、部署操作、回滚操作等功能。而对于微服务的部署方式,包括蓝绿部署、滚动部署以及金丝雀部署。
④进一步提升运维效率
**服务监控:**微服务架构下节点数目众多,需要监控的机器、网络、进程、接口等的数量大大增加,需要一个强大的监控系统,能够提供实时搜集信息进行分析以及实时分析之上的预警。
包括监控服务的请求次数、响应时间分布、最大/最小响应值、错误码分布等。
**服务跟踪:**跟踪一个请求的完整路径,包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息,也叫做全链路跟踪。
通常的服务可以和服务监控做在一起,宏观信息由服务跟踪呈现,微观单个服务/节点的信息由服务监控呈现。服务跟踪目前的实现理论基本都是 Google 的 Dapper 论文。
**服务安全:**内网之间的微服务调用原则上讲应该是都可以互相访问写,一般并不需要权限控制,但有时候限于业务要求,会对接口、数据等方面有安全控制的要求。
此部分可以以配置的方式存在于服务注册中心中,和服务绑定,在请求时由做为服务提供者的服务节点进行安全策略控制。配置则可以存储在配置中心以方便动态修改。
在微服务数量很少的情况下,以上基础设施的优先级自上而下降低。否则,仅仅依赖人工操作,则投入产出比会很低。
还需要提到的是 Docker 容器技术。虽然这个对于微服务并不是必须的,但是容器技术轻量级、灵活、与应用依存、屏蔽环境差异的特性对于持续交付的实现是至关重要的,即使对于传统的单体应用也能够给其带来交付效率的大幅提升。
架构设计模式
在引入微服务之后,传统的单体应用变为了一个一个服务,之前一个应用直接提供接口给客户端访问的架构不再适用。
微服务架构下,针对不同设备的接口做为 BFF 层(Backend For Frontend),也叫做用户体验适配层,负责聚合、编排微服务的数据转换成前端需要的数据。
服务之间的调用则在允许的情况下(允许延迟)尽可能使用异步消息传递方式,如此形成面向用户体验的微服务架构设计模式。
如下图所示:
Client→API Gateway→BFF(Backend For Frontend)→Downstream Microservices:
-
后台采用微服务架构,微服务可以采用不同的编程语言和不同的存储机制。
-
前台采用 BFF 模式对不同的用户体验(如桌面浏览器,Native App,平板响应式 Web)进行适配。
-
BFF、API Orchestration Layer,Edge Service Layer,Device Wrapper Layer 是相同的概念。
-
BFF 不能过多,过多会造成代码逻辑重复冗余。
-
可以将网关承担的功能,如 Geoip、限流、安全认证等跨横切面功能和 BFF 做在同一层,虽然增加了 BFF 层的复杂性,但能够得到性能优势。
服务拆分
微服务架构最核心的环节,主要是对服务的横向拆分。服务拆分就是将一个完整的业务系统解耦为服务,服务需要职责单一,之间没有耦合关系,能够独立开发和维护。
服务拆分不是一蹴而就的,需要在开发过程中不断地理清边界。在完全理清服务之前,尽量推迟对服务的拆分,尤其是对数据库的拆分。
拆分方法如下:
-
基于业务逻辑拆分
-
基于可扩展拆分
-
基于可靠性拆分
-
基于性能拆分
其中,对于无法修改的遗留系统,采用绞杀者模式:在遗留系统外面增加新的功能做成微服务方式,而不是直接修改原有系统,逐步的实现对老系统替换。
拆分过程需要遵守的规范如下:
-
先少后多、先粗后细(粒度)
-
服务纵向拆分最多三层,两次调用:Controller、组合服务、基础服务
-
仅仅单向调用,禁止循环调用
-
串行调用改为并行调用或者异步化
-
接口应该幂等
-
接口数据定义严禁内嵌,透传
-
规范化工程名
-
先拆分服务,等服务粒度确定后再拆分数据库。
微服务框架
上面讲述了微服务架构的众多基础设施,如果每一个基础设施都需要自己开发的话是非常巨大的开发工作。目前市面上已经有不少开源的微服务框架可以选择。
Spring Boot
Spring Boot 是用来简化新 Spring 应用的初始搭建以及开发过程的。其虽然不是微服务框架,但其设计的初衷本质就是微应用的底层框架,因此非常适合用于微服务基础设施的开发以及微服务的应用开发。
尤其对于 Spring 技术栈的团队来说,基于 Spring Boot 开发微服务框架和应用是自然而然的一个选择。
Dubbo&Motan
Dubbo 是阿里开源的服务治理框架。其出现在微服务理念兴起之前,可以看做是 SOA 框架的集大成之作。
但其仅仅包含了微服务基础设施的部分功能,诸如熔断、服务跟踪、网关等都没有实现:
-
**服务发现:**服务发布、订阅、通知。
-
**高可用策略:**失败重试(Failover)、快速失败(Failfast)、资源隔离 - 负载均衡 :最少活跃连接、一致性 Hash、随机请求、轮询等。
-
扩展性 :支持 SPI 扩展(service provider interface)。
-
**其他 :**调用统计、访问日志等。
Motan 则是微博开源的类似 Dubbo 的 RPC 框架,与 Dubbo 相比更轻量级。
Spring Cloud
Spring Cloud 是基于Spring Boot 实现的微服务框架,也可以看做一套微服务实现规范。
基本涵盖了微服务基础设施的方方面面,包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。
其基于 Spring 生态,社区支持非常好。但其很多组件都没有经过生产环境验证,需要慎重选择。
Spring Cloud Netflix 是 Spring Cloud 的一个子项目,是 Spring 对 Netflix OSS 的集成实现。
基于 Netflix 的大规模使用,其中的已经被广泛使用的组件包括:
-
**Eureka:**服务注册和服务发现
-
**Ribbon:**弹性而智能的进程间和服务通讯机制,客户端负载均衡
-
**Hystrix:**熔断器,在运行时提供延迟和容错的隔离
-
**Zuul:**服务网关
此外,另一个子项目 Spring Cloud Alibaba 则是 Alibaba 开源的基于 Spring Boot 的微服务框架,主要是对阿里云服务的支持。
Service Mesh
上述的微服务框架都是侵入式的,服务化的过程都需要进行代码改造。Service Mesh 则是下一代微服务架构,最明显的特征就是无入侵。采用 Sidecar 模式来解决系统架构微服务化后的服务间通信和治理问题。
如下图所示:
目前主流的开源实现包括:
-
**Linkerd 和 Envoy:**以 Sidecar 为核心,关注如何做好 Proxy,并完成一些通用控制平面的功能。缺乏对这些 Sidecar 的管理和控制。
-
**Istio 和 Conduit:**目前最为流行的 Service Mesh 实现方案,集中在更加强大的控制平面(Sidecar 被称为数据平面)功能。前者由 Google 和 IBM 合作,并使用了 Envoy 作为 Sidecar 部分的实现;后者则是 Linkerd 作者的作品。相比起来,Istio 有巨头背景,功能强大,但可用性和易用性一直不高,Conduit 则相对简单、功能聚焦。
限于 Service Mesh 带来的性能延迟的开销以及 Sidecar 对分布复杂性的增加,其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。
Sofastack
蚂蚁金服开源的构建金融级分布式架构的一套中间件。包括微服务开发框架、RPC 框架、服务注册中心、全链路追踪、服务监控、Service Mesh 等一整套分布式应用开发工具。
特别值得一提的是 SOFAMesh。其实对下一代微服务架构 Service Mesh 的大规模落地方案实践,基于 Istio 改进和扩展而来,应该是国内最为成熟的开源 Service Mesh 方案。
此外,需要提到 Kubernetes(K8s),其本身提供了部分的微服务特性支持(通过域名做服务发现),对代码无侵入。但服务调用、熔断这些都需要自己实现。
综上,目前公司技术团队技术栈是 Spring,并且已有服务的实现都是基于 Dubbo。
因此选择 Spring Cloud Netflix 做为基础的微服务框架,对其中不成熟或者缺乏的组件,选择业界更为成熟的组件替代即可:
-
**API 网关:**Zuul。
-
**服务注册中心:**Dubbo。
-
**配置中心:**Disconf。
-
**服务监控&全链路追踪:**CAT。
-
**服务开发框架:**Spring Boot。
-
**日志监控、告警:**ELK+Elasalert。
-
**流量控制:**Sentinel。
-
**消息队列:**Kafka。
看阿里大牛只用这两份文档就能展示全部微服务+Docker完美教程
================================
如今Docker的使用已经非常普遍,特别在一线互联网公司。使用Docker技术可以帮助企业快速水平扩展服务,从而到达弹性部署业务的能力。在云服务概念兴起之后,Docker的使用场景和范围进一步发展,如今在微服务架构越来越流行的情况下,微服务+Docker的完美组合,更加方便微服务架构运维部署落地。
如果您需要容器化与微服务的文档吗,小编收集这2份文档绝对是重量级的!全实战出发,保证让你学习的明明白白的!
Docker 是将程序隔离打包的一种容器技术,也被称为“轻量级”虚拟化技术。
======================================
说到 Docker 就不得不提三个知识点:镜像、容器、仓库 Docker 必学的三要素,那它们具体代码什么意思呢?听我给你慢慢道来。
**镜像:**就相当于是一个 root 文件系统。比如官方镜像 ubuntu:16.04 就包含了完整的一套 Ubuntu16.04 最小系统的 root 文件系统。可以理解成启动容器的模板
容器:容器,其实是一种特殊的进程而已。Docker 为该进程划分一个独立空间
仓库:是用来存储镜像的,可以理解成专门存储镜像的仓库。
镜像(Image)和容器(Container)的关系,就像是面向对象程序设计中的类和实例一样,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
这份文档,将带着你由浅入深,从原理到实践彻底掌握容器化技术!
==============================
内容概要
====
第一部分:
=====
第1章欢迎来到Docker世界
第2章在容器中运行软件
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
![img](https://i-blog.csdnimg.cn/blog_migrate/0cf4ce58d1ca5ff902b6106bcef4d7be.jpeg)
最后
Java架构学习技术内容包含有:Spring,Dubbo,MyBatis, RPC, 源码分析,高并发、高性能、分布式,性能优化,微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书+2021年最新大厂面试题。
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!**
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
![img](https://i-blog.csdnimg.cn/blog_migrate/0cf4ce58d1ca5ff902b6106bcef4d7be.jpeg)
最后
Java架构学习技术内容包含有:Spring,Dubbo,MyBatis, RPC, 源码分析,高并发、高性能、分布式,性能优化,微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书+2021年最新大厂面试题。
[外链图片转存中…(img-GSCIcGrF-1713460772795)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!