目前，当技术人员提到微服务时，首先想到的是实现Spring Cloud和Dubbo等服务的技术框架。这是我们采用微服务的早期阶段的首要考虑因素。然而，随着服务的发展，我们不喜欢框架的便利性和速度带来的业务成就感。相反，服务与多元化通信机制之间的过度服务和冗余增加了业务处理的负担。这当然不是我们想要的微服务，而是大多数公司正在实施的微服务。
因此，我们开始重新审视整个行业，并研究微服务的发展。与过去不同：在早期阶段，我们将更多精力投入到业务中，并在某种程度上“忽视”技术，因为此时我们建立了一种信念，即无论何种形式的“服务形式”必须为商业。服务。
当我们站在全球视野时，我们会看到完成的服务并发现一个漂亮的图形结构。每个节点的界限都很清晰，责任明确；节点之间的链接是平滑的，协议是规则的。在这个时候，我们知道我们终于走上了正确的道路。
我们遵循的原则
经过一段时间的奋斗，我们觉得微服务的重点不在于技术本身，但并不意味着不关注技术。在反思过程中，我们认为微服务中有两个原则无法改变：服务必须围绕业务，服务交互是标准的。我们将原则分为两个阶段：初始阶段和实际阶段。
初步阶段
在初始阶段，遵循第一原则，服务必须以业务为中心。在微服务的早期阶段，重要的是要整理业务，而不是花费大量时间在RPC，服务发现，断路器或Eureka，Docker，Gateway，Dubbo和其他技术框架的概念上。这时，我们关注服务的界限。分工。
这是遵循的两个原则：
确保单一业务服务的有效汇总；
减少服务的相互调用（这是为了避免处理大量的分布式服务）。
在这样的原则下，DDD为我们提供了帮助，并根据业务本身的特点实现了服务的初始阶段。同时，我们发现即使在DDD的指导下，每个服务在不同的业务应用程序中都有不同的聚合形式和调用模式。因此，我们认为微服务本身没有静态模型，一切都围绕着业务动态变化。理性只反映在某个阶段的时间范围内。
实用阶段
业务建模完成后，我们可以清楚地了解每个业务的职责以及与其他业务的关系。从理论层面来看，我们已经完成了业务微服务建模。此时，我们开始实施该服务的实践。在着陆的实践阶段，我们更注重技术框架，而是技术框架的内涵 - 服务互动标准。在这一点上，我们遵循第二个原则：服务的互动是标准的。所谓的服务交互标准从三个层面解释：协议标准，框架标准和接口标准。
协议标准
目前，网络应用的协议相对复杂，我们希望选择一种能够符合业务场景的协议作为通信标准。因此，我们考虑统一的认证和认证协议，加密和解密协议，内部接口交互协议，外围接口服务协议等。每个协议履行其职责以支持服务通信的标准化。协议标准不仅为平台本身提供服务，还与其他业务部门进行通信。它只需遵循协议标准即可实现业务单元之间的快速链接。
框架标准
为了支持业务，我们不依赖任何自动代码生成框架，而是基于我们的协议支持，选择最小的服务操作框架来构建统一的业务单元支持框架。这里需要注意的是，框架标准需要考虑业务特征，协议特征，而不能一概而论，因此其有效性可能仅限于当前的业务平台本身。构建标准框架的好处是可以为应用程序内的所有业务单元快速复制，从而简化了由于各自开发框架的差异而导致的联合阶段的问题。
接口标准
有两种类型的接口：服务内部接口和业务服务接口。无论哪种接口也遵循标准化原则。
服务内部接口的核心在于压缩协议，加快了服务的处理速度。因此，可以采用由诸如RPC的有效协议支持的接口模式。服务服务接口的核心是指示服务承载的信息，因此更适合采用restful接口规范。接口设计需要涵盖但不限于标准化请求方法，统一参数处理，统一结果返回，统一异常处理和统一日志处理。
服务拆分和聚合
先决条件：服务拆分和聚合在本文中，我们暂不考虑Web的微服务设计，只考虑后端服务的拆分和聚合实践。
需要遵循服务拆分和聚合的原则：服务必须围绕业务。然而，事实是，在追求“开源集成”的背景下，纯粹的业务部门需要消耗巨大的成本来实现业务需求而不使用第三方工具，并且同一工具也可以使用不同的业务单元。强烈依赖。因此，在服务拆分和聚合中，我们考虑实现两种形式：业务支持和工具支持。
贸易支持
业务支持需要考虑业务服务对象和业务内部逻辑。作为整个业务单元的外部形式，业务服务对象可以通过命名明确表示其覆盖范围；业务的内部逻辑需要执行业务单元的细粒度拆分，实体类可以包括多个其他相关实体。对象（当然，如果服务拆分足够详细，内部逻辑也可以用作单独的业务单元，但这会增加业务的直接通信负载）。基于业务内部逻辑构建业务服务对象的真实场景。 DDD实践方法可以依赖于拆分的具体细节（当然，它需要根据业务进行调整，没有通用的方法）。工具支持
工具支持需要与业务考虑相结合，分为两种类型：通用工具和专用工具。通用工具旨在为所有业务部门运营提供统一的支持平台，从而减少在工具维护上的投入，使业务开发人员能够专注于业务实施。通用通用工具包包括统一日志处理，统一拦截处理和返回数据统一封装。 ，异常处理等；特殊工具专注于特定的业务部门，由业务部门自己维护（例如迭代升级）。工具支持层不提供外部restful或rpc接口，外部表示是编译的依赖工具包（例如Github管理接口的包）。
服务架构选择
根据实施原则完成服务拆分后，我们需要考虑适当的登陆选择。选择方案中有许多因素需要考虑：技术背景（尤其是团队中编程语言的设置），服务支持工具（注册中心，网关，服务调用，负载均衡数据库等），服务运行工具（tomcat） ，jetty，Jboss等），服务部署工具（物理部署，虚拟化，容器等），协议支持工具集合（http，rpc，mtqq，idoc等）。但无论您如何选择，您都必须结合团队开发人员的技能支持。这是我们选择的核心因素，因为白盒子总是比黑盒子更安全，更可控。
这是我们的技术堆栈选择框架（仅对我们熟悉），并不涉及技术框架的比较。
服务开发框架：springboot，dubbo，grpc，ServiceMesh（基于ServiceMesh的开发服务框架）
分布式存储/注册中心：Zookeeper，Consul，Eureka，Etcd
服务网关：Kong，Openresty，Spring云Zuul，Spring云网关
负载均衡：nginx，spring cloud ribbon，haproxy，Kubernetes服务
服务远程调用：春云假装
缓存服务：memchace，redis
数据库：mariadb，mysql
消息服务：RabbitMQ，NATS，Kafka
配置中心：spring cloud config，Apollo，Consul
事件机制：云事件
服务编排：指挥，Kubernetes
服务治理：Spring cloud，Dubbo，ServiceMesh基于消息机制的分布式事务处理（根据CAP或BASE理论模型的实现）
业务运行工具：jvm，nginx或其他运营环境支持
开发编译工具：Jenkins，maven，gitlab
界面文档：Swagger
部署工具：物理部署（jar包或可运行的已编译二进制文件）虚拟化部署（虚拟映像模板）容器化部署（Docker）
在登陆过程中，我们根据团队的技术特点选择了Spring Cloud所涵盖的技术堆栈。易于使用，快速入门。在操作阶段选择具有服务编排功能的Kubernetes容器化运行时环境，并且可以与Devops工具链一起快速迭代地部署。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 反应内存泄漏FAQ解决方案

• 分享到：