网站建设免费免代码,做机电预算的网站,网络科技公司网站源码下载,自己做小程序要钱吗目录
一、前言
二、微服务架构的设计原则
1.拆分足够微
2.轻量级通信
3.单一职责原则
4.领域驱动原则
三、微服务架构的核心话题
1.服务拆分
2.服务注册与发现
3.负载均衡
4.API网关
5.服务部署与发布
四、总结 一、前言
毫无疑问#xff0c;微服务架构的设计原…目录
一、前言
二、微服务架构的设计原则
1.拆分足够微
2.轻量级通信
3.单一职责原则
4.领域驱动原则
三、微服务架构的核心话题
1.服务拆分
2.服务注册与发现
3.负载均衡
4.API网关
5.服务部署与发布
四、总结 一、前言
毫无疑问微服务架构的设计原则和核心话题是本文要讨论的重点也是打算从零基础开始构建微服务架构需要事先考虑、规划的。一个好的产品、应用能否稳定运行持续开发满足业务需求能否经得起现实的考验就需要在设计阶段考虑很多、很多以确保它的健壮性。
当我们从单体架构的应用走向基于微服务的架构时首先会面临一个很棘手的问题是如何进行服务的拆分服务的拆分粒度应该如何衡量怎样拆分的服务才算是“微”。接着将又会面临这么多的服务又如何关联起来呢如何有效的相互间通信呢如何高效的部署呢……
本文我将从微服务架构的设计原则、核心话题两大方面展开讨论希望能够对你构建一个微服务架构的应用有所帮助。 二、微服务架构的设计原则
软件架构的设计原则、方法论在很大程度上能够指导、提醒我们应该遵循什么的原则、规范能让软件架构更加健壮、稳固并易于开发、扩展、维护等。
1.拆分足够微
在解决复杂的问题时我们倾向于将问题划分成若干个小问题来解决所谓“大事化小小事化了”。单体架构的应用随着时间的推移会变得越来越臃肿越来越难以维护适当的做“减法”可以解决单体架构存在的这些问题。
将单体架构的应用拆分为微服务架构的应用时服务的拆分粒度问题成为了重中考虑的问题。粒度太大拆分的不够充分便和单体架构没有太大的区别更不能发挥出微服务的优势。如果拆分的太细又将会面临着服务数量太多而引发的服务管理、服务间调用的问题。对于如何“微”才算是足够的“微”是没有标准的衡量计算方法的。
微服务不是说越小越好。服务越小微服务架构的优点和缺点也就会越来越明显。服务越小微服务的独立性就越高但同时微服务的数量也会增加管理就会存在很大的问题成为一个新的挑战这也就是常常所被提到的“这么多的服务该服务管理啊”问题。
服务的拆分足够微可以按照某种方式、规则拆分通常可以按照业务模块、业务场景等进行拆分尽量避免服务间的相互依赖做到高内聚低耦合。紧密关联的处理放在一个服务内但避免在服务与服务之间共享数据。 2.轻量级通信
在单体架构的应用中可直接通过简单的方法调用就能进行通信但在微服务架构中由于服务都是跨域进程甚至是跨主机的组件只能通过REST、Web服务或RPC类似的机制在网络上进行通信。
因为服务划分的已经足够小了服务间的通信可能会比较频繁考虑到性能、响应时间等方面则服务间通信应采用轻量级的通信协议如同步的REST异步的AMQP、STOMP、MQTT等。在实时性要求不高的场景下采用REST通信是不错的选择REST是基于HTTP协议可方便进行跨域访问或跨防火墙的设置并且消息格式可以统一为XML或JSON格式方便开发人员阅读和理解。如果服务间通信比较频繁有比较高的要求可采用消息通信的方式如Kafka、MQ等类似的消息中间件。如果不考虑对外提供访问的话可采用gRPC的通信方式因为gRPC是基于Netty的通信效率更高。
3.单一职责原则
当服务粒度过粗时服务内部很容易产生耦合。如果多人开发同一个服务很容易因为耦合过大造成代码修改重合不利于后期维护。确保每个服务职责单一这也是用来确定服务拆分边界的一个原则遵循“高内聚、低耦合”。
必须要对自己的产品和业务的了解才能更准确的确定服务边界让各个服务满足单一的业务职责避免职责交叉。
4.领域驱动原则
领域驱动设计(Domain Driven Design)是一套综合软件系统分析和设计的面向对象建模方法。一个微服务就应该能够反映出某个业务的领域模型使用领域驱动设计不但可以降低微服务环境中通用语言的复杂度而且可以帮助团队搞清楚领域的边界理清上下文边界。
建议将每个微服务都设计成一个DDD限界上下文为微服务提供了一个逻辑边界。每个独立的团队负责一个逻辑上定义好的系统切片负责与一个领域或业务功能相关的全部开发最终团队开发出的代码更加易于理解和维护。
三、微服务架构的核心话题
基于微服务架构的应用将面临着许多选择、争议等讨论的核心话题这些核心话题将会在你接下来的微服务架构生涯里不断出现并成为讨论的焦点。在此我觉得有必要进行汇总整理让你觉得它存在的必要性能为你之所用。
1.服务拆分
服务拆分首先关注的就是服务的颗粒度可遵循设计原则——拆分足够微通过DDD(领域驱动设计)的指导将某个领域的功能进行聚合成为一个服务。
对于一个大型复杂的单体应用而言选择先拆分哪个模块是一个问题。一般考虑先从容易、简单被拆分的模块开始在拆分简单模块过程中不断积累微服务的经验逐步拆分掉复杂、繁重业务的核心模块。同时寻找那些和其他功能业务重合度低、耦合度低且自身变化较为缓慢的基础服务将它们拆分为微服务。
决定了拆分哪些模块要拆分成多个微服务后接下来就要划清服务拆分的边界将服务边界和接口顺理清楚。确定哪些应该包含进来哪些不应该包含进来哪些接口需要重新设计哪些可以重复利用。
如下图所示展示了一个单体应用拆分为多个微服务的过程。一旦拆分完后各个服务就可以独立开发、部署和扩展。 服务的拆分不单单指功能的拆分如上图所示还得考虑数据库的拆分 确保降低功能逻辑层、数据访问层的耦合度。
2.服务注册与发现
微服务架构的特点是服务的数量众多这些众多的服务需要一个统一的服务注册平台来进行服务的管理。每个微服务实例在启动后将自己的实例信息注册到服务注册表或服务注册中心。服务的调用方若想获取可用服务实例的列表则需要从服务注册表中去获取相关的信息。
当服务实例失效或down掉以后服务实例的信息就要从服务注册表中移除即服务注销。服务注册表是用于维护所有可用的服务实例的地方服务注册表一方面要接收微服务实例的接入另一方面当服务实例不可用时需要及时将服务实例从注册表中清楚。下图展示了服务注册与服务实例的关系。 服务注册与发现组件或框架有很多如Eureka、Consul、etcd等都提供了服务注册表的功能可供大家进行选择。
3.负载均衡
在微服务架构中负载均衡是必须使用的技术通过它来实现系统的高可用、集群扩容等功能。负载均衡通常分为两种服务端负载均衡和客户端负载均衡。通常所说的负载均衡均指服务器端的负载均衡可通过软件或硬件设备来实现软件如Nginx、LVS等硬件如F5、A10等硬件负载均衡设备成本较高大部分采用的是软件方式。架构图如下 通过软件或硬件实现负载均衡都会维护一个服务端清单利用心跳检测等手段进行清单维护保证清单中都是可以正常访问的服务节点。当用户发送请求时会先到达负载均衡器一般作为一个服务负载均衡器根据负载均衡算法轮训、随机、加权轮训从可用的服务端列表中取出一台服务端的地址接着进行转发降低系统的压力。
4.API网关
考虑到微服务架构中服务的数量很多为了便于服务对外统一的管理API网关的引入是必不可少的。API网关旨在提供统一的API入口点来管理多个服务内部API可方便实现对平台众多服务接口进行管控如对访问服务的身份认证、业务鉴权、流量并发控制、API调用的计量或计费等。
API网关常用于以下场景 黑白名单实现例如通过IP地址来禁止访问某些服务的某些功能。 日志实现日志访问的记录用于分析访问、处理性能指标并将分析结果提供给其他模块使用如运维平台的统计功能。 协议适配实现通信协议校验、适配转换的功能。 身份认证负责外部系统的访问身份认证。 计流限流实现微服务访问流量计算基于流量计算分析进行限流等。 路由API网关的核心功能实现请求的转发。
API网关的引入为微服务架构应用带来诸多的好处如下 避免将内部信息/接口泄露给外部 能够将对外发布的API与微服务内部的API区分开来使得各个微服务在添加或变更时能有明确的安全边界避免多过的对外暴露。 为微服务添加额外的安全层能够提供一套额外的保护层用以应对SQL注入、Dos攻击等其中系统的权限控制可以再这一层来实施。 支持多种混合通信协议考虑到微服务架构中各个微服务的平台与语言的多样性通常将对外提供基于HTTP或REST的API接口而内部微服务将根据自身服务情况采用不同的通信协议(如ProtoBuf、RPC等)。API网关则跨域这些内部不同协议的微服务提供一个基于REST的统一外部API。 减低构建微服务的复杂性基于微服务架构应用的复杂性如API令牌、访问控制、限速限流等每一项功能的添加对会额外对各个服务带来影响从而影响微服务的开发周期。这些功能如果在API网关上统一处理则会从代码层面进行了有效的隔离使得不会影响其他微服务这样更有利于其他微服务只需关注于实际的业务开发。
常见的API网关实现方式很多如Nginx、Kong、Spring Cloud Zuul、Trfk等。
5.服务部署与发布
单体应用被拆分为微服务后随着微服务的数量增多部署就成了问题使得部署的复杂性提高了不少。所以微服务的部署更加倾向于使用具有相互之间隔离的主机/虚拟机来实现服务的部署使得服务能够独立的部署、测试、发布、升级。
目前比较好的服务部署方式就是把各个微服务打包成Docker镜像这样就保障避免了不同主机环境对部署产生的影响。使用Docker部署并结合Jenkins进行CI/CD,使得构建、发布、启动变得更加快捷。
下图就是服务部署、发布流程。 四、总结
一个微服务架构的应用从最初的设计到逐步成型是需要经过不断的迭代开发、摸索来完善的上述只是列举出了我个人认为需要重点关注的点以供大家参考如有遗漏不足望大家建议补充、完善。
