南宁霸屏网站开发,wordpress全部教程,深圳广告设计公司深圳画册设计,煜阳做网站目录
什么是微服务
定义
特点
利弊
引入时机
需要哪些治理环节
从单体架构到微服务架构的演进
单体架构
集群和垂直化
SOA
微服务架构
如何实现微服务架构
服务拆分
主流微服务解决方案
基础设施
下一代微服务架构Service Mesh
什么是Service Mesh#xff1f…
目录
什么是微服务
定义
特点
利弊
引入时机
需要哪些治理环节
从单体架构到微服务架构的演进
单体架构
集群和垂直化
SOA
微服务架构
如何实现微服务架构
服务拆分
主流微服务解决方案
基础设施
下一代微服务架构Service Mesh
什么是Service Mesh
Service Mesh的实现原理 什么是微服务
定义
微服务的概念最早是在2014年由Martin Fowler和James Lewis共同提出(原文链接https://martinfowler.com/articles/microservices.html)他们定义了微服务是由单一应用程序构成的小服务拥有自己的进程与轻量化处理服务依业务功能设计以全自动的方式部署与其他服务使用HTTP API通讯。同时服务会使用最小规模的集中管理 (例如Docker)技术服务可以用不同的编程语言与数据库等。 特点
从微服务的定义当中我们可以提炼出如下几个微服务的核心特点
一组小的服务(涉及到服务拆分的粒度问题后面会涉及)独立进程轻量级通信(Rest和RPC)独立部署 利弊
微服务带来的好处
清晰的模块边界各自独立部署互不影响各个服务可选择不同的技术实现
微服务带来的弊端
分布式复杂性(从单体到微服务系统内部复杂度降低同时外部复杂度增加)数据一致性问题运维复杂度更高测试复杂度更高 引入时机
前期业务不复杂的情况下不建议引入微服务。对于一个业务一开始就应该是怎么快怎么来快速迭代快速验证产品。随着业务不断发展越来越复杂整个生产力开始下降的时候就可以开始考虑引入微服务了。
在引入微服务的时候整体的一个思路是选择一个非核心模块开始微服务化将微服务整套核心基础设施落地(核心基础设施后面会涉及)然后渐进式地去微服务化其他模块稳步前进。 需要哪些治理环节
服务注册中心
服务通信
服务配置中心
统一网关
自动化部署
可观测性(日志Logs、监控Metrics、链路追踪Trace) 从单体架构到微服务架构的演进
单体架构
早期开发的时候一个war包或者jar包里面包含了一个应用的所有功能这样的架构我们叫作单体架构。单体架构足够简单可以快速开发和上线适用于项目初期业务简单、用户量不大的情况。 集群和垂直化
集群横向增加服务器将单台机器变成由多台机器组成的集群。
垂直化按照业务的垂直领域进行划分降低业务的耦合度同时提高应用的可伸缩性。 SOA
面向服务架构核心目标是把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务这些被提取出来的共享服务相对来说比较独立并且可以重用。所以在SOA中服务是最核心的抽象手段业务被划分为一些粗粒度的业务服务和业务流程。
SOA解决的问题信息孤岛共享业务重用。 微服务架构
我们可以简单地理解多个微服务可以组成一个SOA服务。
由于SOA和微服务它们的关注点不同就导致了它们之间有非常大的区别
SOA关注的是服务的重用性和信息孤岛问题微服务关注的是业务解耦。
解耦是降低业务之间的耦合度重用性关注的是服务的复用。
微服务架构使得服务粒度细化之后开发运维也变得更加重要和容器技术也结合得更加紧密。 如何实现微服务架构 服务拆分
更多的时候大家可能都是按照业务流程来进行服务的拆分的。除此之外我们还可以按照性能、业务重要程度、可用性、稳定性这些维度来进行微服务的拆分具体采取什么方式可以视具体情况而定。
那关于服务的粒度我们应该如何把握呢粒度太细或太粗都不太合适粒度太细会导致开发、测试、运维更加复杂整体性能会降低等粒度太粗又会导致达不到我们的预期服务之间依赖太大。这里有一个技巧三个火枪手原则。拆分微服务的数量服务端开发人数/3。
什么是三个火枪手原则平均3个开发人员负责一个微服务。
为什么不是1个人没有备份人员一个人思维有局限。
为什么不是2个人异常情况下一个人压力会比较大另外两个人维护的服务复杂度可能偏低。
为什么不是4个或者更多开发人员多了之后每个人不一定能掌握单个服务的所有细节。 主流微服务解决方案
Spring Cloud Alibaba(目前用得比较多的方案)Spring Cloud NetflixSpringBoot K8sDubbo 基础设施
微服务整个基础设施会包括下面这些内容我们一起来看看。
服务接入层服务网关服务流控服务降级服务安全。服务运行层服务注册服务发现服务路由服务容错。技术支撑层接口框架分布式事务自动化测试容器编排自动化部署灰度发布服务监控服务跟踪。基础设施层配置中心日志中心分布式锁消息队列。
上面说了这么多那么它们的优先级是怎么样的呢服务运行层 服务接入层 基础设施层 技术支撑层。其中微服务框架的核心是服务注册、服务发现和服务路由。 下一代微服务架构Service Mesh
什么是Service Mesh
Service Mesh是一种新型的用于处理服务与服务之间通信的技术尤其适用以云原生应用形式部署的服务能够保证服务与服务之间调用的可靠性。在实际部署时Service Mesh 通常以轻量级的网络代理的方式跟应用的代码部署在一起从而以应用无感知的方式实现服务治理。
Service Mesh 以轻量级的网络代理的方式与应用的代码部署在一起用于保证服务与服务之间调用的可靠性这与传统的微服务架构有着本质的区别这么做主要是出于两个原因
跨语言服务调用的需要云原生应用服务治理的需要
Service Mesh的实现原理
Service Mesh 实现的关键就在于两点一个是上面提到的轻量级的网络代理也叫 SideCar它的作用就是转发服务之间的调用一个是基于 SideCar 的服务治理也被叫作 Control Plane它的作用是向 SideCar 发送各种指令以完成各种服务治理功能。
1.SideCar 2.Control Plane
既然 SideCar 能实现服务之间的调用拦截功能那么服务之间的所有流量都可以通过 SideCar 来转发这样的话所有的 SideCar 就组成了一个服务网格再通过一个统一的地方与各个 SideCar 交互就能控制网格中流量的运转了这个统一的地方就在 Sevice Mesh 中就被称为 Control Plane。 Service Mesh 在诞生不到两年的时间里取得令人瞩目的发展Google、IBM 领导的 Istio是 Service Mesh 技术的代表之作。除吃之外还有微博的 Weibo Mesh、华为公有云 Service Mesh 以及蚂蚁金服的 SOFA Mesh 等。
