作者： 雷火电竞首页 来源： 日期：2023-11-18 12:28
泉源：法式猿技术大咖毫无疑问，微服务架构的设计原则和焦点话题是本文要讨论的重点，也是计划从零基础开始构建微服务架构需要事先思量、计划的。一个好的产物、应用能否稳定运行，连续开发，满足业务需求，能否经得起现实的磨练，就需要在设计阶段思量许多、许多，以确保它的结实性。当我们从单体架构的应用走向基于微服务的架构时，首先碰面临一个很棘手的问题是如何举行服务的拆分，服务的拆分粒度应该如何权衡，怎样拆分的服务才算是“微”。
接着将又碰面临，这么多的服务又如何关联起来呢？如何有效的相互间通信呢？如何高效的部署呢…… 本文我将从微服务架构的设计原则、焦点话题两大方面展开讨论，希望能够对你构建一个微服务架构的应用有所资助。微服务架构的设计原则 软件架构的设计原则、方法论，在很大水平上能够指导、提醒我们应该遵循什么的原则、规范，能让软件架构越发结实、稳固，并易于开发、扩展、维护等。
拆分足够微 在解决庞大的问题时，我们倾向于将问题划分成若干个小问题来解决，所谓“大事化小，小事化了”。单体架构的应用，随着时间的推移，会变得越来越臃肿，越来越难以维护，适当的做“减法”，可以解决单体架构存在的这些问题。将单体架构的应用拆分为微服务架构的应用时，服务的拆分粒度问题，成为了重中思量的问题。粒度太大，拆分的不够充实，便和单体架构没有太大的区别，更不能发挥出微服务的优势。
如果拆分的太细，又将碰面临着服务数量太多而引发的服务治理、服务间挪用的问题。对于如何“微”才算是足够的“微”，是没有尺度的权衡盘算方法的。微服务不是说越小越好。服务越小，微服务架构的优点和缺点也就会越来越显着。
服务越小，微服务的独立性就越高，但同时微服务的数量也会增加，治理就会存在很大的问题，成为一个新的挑战，这也就是经常所被提到的“这么多的服务，该服务治理啊？”问题。服务的拆分足够微，可以根据某种方式、规则拆分，通常可以根据业务模块、业务场景等举行拆分，只管制止服务间的相互依赖，做到高内聚低耦合。
精密关联的处置惩罚，放在一个服务内，但制止在服务与服务之间共享数据。轻量级通信 在单体架构的应用中，可直接通过简朴的方法挪用就能举行通信，但在微服务架构中，由于服务都是跨域历程，甚至是跨主机的，组件只能通过REST、Web服务或RPC类似的机制在网络上举行通信。因为服务划分的已经足够小了，服务间的通信可能会比力频繁，思量到性能、响应时间等方面，则服务间通信应接纳轻量级的通信协议，如：同步的REST，异步的AMQP、STOMP、MQTT等。在实时性要求不高的场景下，接纳REST通信是不错的选择，REST是基于HTTP协议，可利便举行跨域会见或跨防火墙的设置，而且消息花样可以统一为XML或JSON花样，利便开发人员阅读和明白。
如果服务间通信比力频繁，有比力高的要求，可接纳消息通信的方式，如：Kafka、MQ等类似的消息中间件。如果不思量对外提供会见的话，可接纳gRPC的通信方式，因为gRPC是基于Netty的，通信效率更高。单一职责原则 当服务粒渡过粗时，服务内部很容易发生耦合。
如果多人开发同一个服务，很容易因为耦合过大造成代码修改重合，倒霉于后期维护。确保每个服务职责单一，这也是用来确定服务拆分界限的一个原则，遵循“高内聚、低耦合”。
必须要对自己的产物和业务的相识，才气更准确简直定服务界限，让各个服务满足单一的业务职责，制止职责交织。领域驱动原则 领域驱动设计(Domain Driven Design)，是一套综合软件系统分析和设计的面向工具建模方法。
一个微服务，就应该能够反映出某个业务的领域模型，使用领域驱动设计，不光可以降低微服务情况中通用语言的庞大度，而且可以资助团队搞清楚领域的界限，理清上下文界限。建议将每个微服务都设计成一个DDD限界上下文，为微服务提供了一个逻辑界限。每个独立的团队卖力一个逻辑上界说好的系统切片，卖力与一个领域或业务功效相关的全部开发，最终团队开发出的代码越发易于明白和维护。微服务架构的焦点话题 基于微服务架构的应用，将面临着许多选择、争议等讨论的焦点话题，这些焦点话题将会在你接下来的微服务架构生涯里不停泛起，并成为讨论的焦点。
在此，我以为有须要举行汇总整理，让你以为它存在的须要性，能为你之所用。服务拆分 服务拆分首先关注的就是服务的颗粒度，可遵循设计原则——拆分足够微，通过DDD(领域驱动设计)的指导，将某个领域的功效举行聚合成为一个服务。
对于一个大型庞大的单体应用而言，选择先拆分哪个模块，是一个问题。一般思量先从容易、简朴被拆分的模块开始，在拆分简朴模块历程中，不停积累微服务的履历，逐步拆分掉庞大、繁重业务的焦点模块。同时，寻找那些和其他功效业务重合度低、耦合度低，且自身变化较为缓慢的基础服务，将它们拆分为微服务。
决议了拆分哪些模块，要拆分成多个微服务后，接下来就要划清服务拆分的界限，将服务界限和接口顺理清楚。确定哪些应该包罗进来，哪些不应该包罗进来，哪些接口需要重新设计，哪些可以重复使用。
如下图所示，展示了一个单体应用拆分为多个微服务的历程。一旦拆分完后，各个服务就可以独立开发、部署和扩展。服务的拆分，不但单指功效的拆分，如上图所示，还得思量数据库的拆分 ，确保降低功效逻辑层、数据会见层的耦合度。
服务注册与发现 微服务架构的特点是服务的数量众多，这些众多的服务需要一个统一的服务注册平台来举行服务的治理。每个微服务实例在启动后，将自己的实例信息注册到服务注册表或服务注册中心。服务的挪用方若想获取可用服务实例的列表，则需要从服务注册表中去获取相关的信息。
当服务实例失效或down掉以后，服务实例的信息就要从服务注册表中移除，即：服务注销。服务注册表是用于维护所有可用的服务实例的地方，服务注册表一方面要吸收微服务实例的接入，另一方面当服务实例不行用时，需要实时将服务实例从注册表中清楚。下图展示了服务注册与服务实例的关系。
服务注册与发现组件或框架，有许多，如：Eureka、Consul、etcd等，都提供了服务注册表的功效，可供大家举行选择。负载平衡 在微服务架构中，负载平衡是必须使用的技术，通过它来实现系统的高可用、集群扩容等功效。负载平衡通常分为两种：服务端负载平衡和客户端负载平衡。
通常所说的负载平衡均指服务器端的负载平衡，可通过软件或硬件设备来实现，软件如：Nginx、LVS等，硬件如：F5、A10等，硬件负载平衡设备成本较高，大部门接纳的是软件方式。架构图如下： 通过软件或硬件实现负载平衡都市维护一个服务端清单，使用心跳检测等手段举行清单维护，保证清单中都是可以正常会见的服务节点。当用户发送请求时，会先到达负载平衡器（一般作为一个服务），负载平衡器凭据负载平衡算法（轮训、随机、加权轮训）从可用的服务端列表中取出一台服务端的地址，接着举行转发，降低系统的压力。
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、Træfɪk等。服务部署与公布 单体应用被拆分为微服务后，随着微服务的数量增多，部署就成了问题，使得部署的庞大性提高了不少。
所以，微服务的部署越发倾向于使用具有相互之距离离的主机/虚拟机来实现服务的部署，使得服务能够独立的部署、测试、公布、升级。现在比力好的服务部署方式就是把各个微服务打包成Docker镜像，这样就保障制止了差别主机情况对部署发生的影响。使用Docker部署，并联合Jenkins举行CI/CD，使得构建、公布、启动变得越发快捷。下图就是服务部署、公布流程。
总结 一个微服务架构的应用，从最初的设计到逐步成型，是需要经由不停的迭代开发、探索来完善的，上述只是枚举出了我小我私家认为需要重点关注的点，以供大家参考。
本文来源：雷火电竞首页-www.hbwyjx.com
