微服务

一、概念

微服务，又名微服务架构，是一种架构风格，它将应用程序构建为以业务领域建模的小型自治服务的集合。在微服务架构中，每个服务都是自包含的，并且实现了单一的业务能力。

可以把微服务看作是SOA的一种最佳实践。

1.1 传统架构与微服务的区别

对于单体应用，所有功能最初都在共享单个数据库的单个实例下。但是，对于微服务，每个特性都被分配了一个不同的微服务，处理它们自己的数据，并执行不同的功能。

1.2 微服务架构

• 来自不同设备的不同客户端尝试使用不同的服务，例如搜索、构建、配置和其他管理功能。
• 所有服务都根据其域和功能进行分离，并进一步分配给各个微服务。
• 这些微服务有自己的负载均衡器和执行环境来执行它们的功能，同时在自己的数据库中捕获数据。
• 所有微服务都通过无状态服务器（REST 或消息总线）相互通信。
• 微服务借助服务发现了解其通信路径，并执行自动化、监控等操作功能。
• 然后，微服务执行的所有功能都通过 API 网关与客户端通信。
• 所有内部点都从 API 网关连接。因此，任何连接到 API 网关的人都会自动连接到整个系统。

1.3 微服务功能

• 解耦——系统内的服务在很大程度上是解耦的。因此，整个应用程序可以轻松构建、更改和扩展。
• 组件化——微服务被视为可以轻松更换和升级的独立组件。
• 业务能力——微服务非常简单，专注于单一能力。
• 自治——开发人员和团队可以彼此独立工作，从而提高速度。
• 持续交付——通过软件创建、测试和批准的系统自动化，允许频繁发布软件。
• 责任——微服务不关注应用程序作为项目。相反，他们将应用程序视为他们负责的产品。
• 去中心化治理——重点是为正确的工作使用正确的工具。这意味着没有标准化的模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题。
• 敏捷性——微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃。

1.4 微服务的优势

• 独立开发——所有微服务都可以根据各自的功能轻松开发
• 独立部署——根据他们的服务，他们可以单独部署在任何应用程序中
• 故障隔离——即使应用程序的一项服务不工作，系统仍然继续运行
• 混合技术栈——不同的语言和技术可用于构建同一应用程序的不同服务
• 粒度缩放——单个组件可以根据需要进行缩放，无需将所有组件一起缩放

二、实现一个微服务

2.1 组件服务化

我们用go实现一个微服务：

• kit：一个微服务的基础库（框架）

• service：业务代码+kit依赖+第三方依赖组成的业务微服务

• RPC+message queue：轻量级通讯

多个微服务compose成一个usecase

2.2 按业务组织服务

服务提供的能力和业务功能对应，开发团队对软件在生产环境负全部责任

2.3 去中心化

每个服务面对的场景不同，可以针对性的选择合适的技术解决方案。数据、治理、技术去中心化。所有的资源都是隔离的。

2.4 基础设施自动化

自动化包括测试和部署

CICD：gitlab+gitlab hooks +kubernetes

testing: 测试环境、单元测试、API自动化测试

在线运行时：K8S，已经一系列Prometheus、ELK、conrtol panle

2.5 可用性&兼容性设计

著名的Design For Failure思想，微服务架构采用粗粒度的进程间通信，引入了额外的复杂性和需要处理的新问题，如网络延迟、消息格式、负载均衡和容错。

在服务需要变更时需要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏。发送时要保守，接收性要开放。最小化的传送必要的信息，要最大限度的容忍冗余数据，保证兼容性。