微服务教程：什么是 Archi结构与实例
伊利亚·霍尔
什么是微服务？
微服务 是一种面向服务的架构模式，其中应用程序被构建为各种最小独立服务单元的集合。它是一种 软件工程 该方法侧重于将应用程序分解为具有明确定义接口的单一功能模块。这些模块可以由负责整个服务生命周期的小团队独立部署和运营。
“微”指的是微服务的规模，它必须能够由单个开发团队（5到10名开发人员）管理。在这种方法论中，大型应用程序被拆分成最小的独立单元。
什么是单体 Archi结构？
通俗地说，单体架构就像一个大容器，应用程序的所有软件组件都被打包成一个整体。让我们以一个电子商务网站为例，探讨一下单体架构的应用。
单片 Archi电子商务应用结构
在任何电子商务应用程序中，都有一些标准功能，例如搜索， Rev查看和评分以及支付功能。客户可以通过浏览器或应用程序访问这些功能。当电子商务网站的开发者部署应用程序时，它是一个单一的单体应用。不同功能（例如搜索、评分和支付）的代码是分开的。 Rev用户评价、评分和支付功能都运行在同一台服务器上。为了扩展应用程序，您需要运行这些应用程序的多个实例（服务器）。
什么是微服务 Archi结构？
微服务 Archi质地 是一种架构开发风格，允许将应用程序构建为针对业务领域开发的小型自主服务集合。它是结构化风格架构的一种变体，有助于将应用程序安排为松散耦合的服务集合。微服务 Archi结构包含细粒度的服务和轻量级协议。
让我们以一个采用微服务架构开发的电子商务应用程序为例。在这个微服务架构示例中，每个微服务都专注于一项单一的业务功能。搜索、评分和 Review 和 Payment 各自有自己的实例（服务器），并且彼此通信。
微服务 Archi质地
在整体式 Archi在传统架构中，所有组件都整合到一个单一模块中。但在微服务架构中…… Archi在架构中，它们被分散成相互通信的各个模块（微服务），如上面的微服务示例所示。
微服务之间的通信是无状态通信，其中每对请求和响应都是独立的。因此，微服务可以轻松通信。在微服务中 Archi在这种架构下，数据是联合的。每个微服务都有自己独立的数据存储。
微服务与单体 Archi质地
| 微服务 | 单片 Archi质地 |
|---|---|
| 整个应用程序的每个单元都应该是最小的，并且它应该能够实现一个特定的业务目标。 | 使用同一套代码库实现所有业务目标。 |
| 服务启动速度相对较快。 | 服务启动需要更多时间。 |
| 故障隔离很容易。即使一项服务中断，其他服务也能继续运行。 | 故障隔离非常困难。如果某个特定功能出现故障，整个系统都会崩溃。要解决这个问题，需要重新构建、重新测试并重新部署应用程序。 |
| 所有微服务都应该松耦合，这样在一个微服务中所做的更改就不会影响其他微服务。 | 单体架构耦合性很强，一个模块的代码改动会影响其他模块。 |
| 企业可以将更多资源投入到能产生更高投资回报率的服务中。 | 由于各项服务并非相互隔离，因此无法进行单独的资源分配。 |
| 可以为频繁使用的服务分配更多硬件资源。以上述电子商务示例为例，与支付相比，更多用户会查看产品列表和进行搜索，因此可以为搜索和产品列表微服务分配更多资源。 | 应用程序扩展既有挑战性又很浪费。 |
| 微服务始终保持一致性和持续可用性。 | 由于整个过程需要从头开始，开发工具不堪重负。 |
| 数据采用联合方式。这使得各个微服务能够采用最适合自身需求的数据模型。 | 数据集中化。 |
| 小而精的团队，并行且更快速的开发。 | 需要庞大的团队和大量的团队管理工作。 |
| 一个微服务的数据模型的改变不会影响其他微服务。 | 数据模型的变更会影响整个数据库。 |
| 通过使用定义完善的接口与其他微服务进行交互。 | 不适用。 |
| 微服务的工作原则是专注于产品，而不是项目。 | 注重整个项目。 |
| 代码库之间没有交叉依赖。您可以针对不同的微服务使用不同的技术。 | 一个功能或程序依赖于其他功能或程序。 |
微服务挑战
- 微服务之间相互依赖，它们之间需要相互通信。
- 与单片系统相比，需要监控的服务更多，这些服务是使用不同的 编程语言.
- 由于它是一个分布式系统，因此它是一个本质上复杂的模型。
- 不同的服务将有各自的机制，导致大量内存用于存储非结构化数据。
- 有效的管理和团队合作是防止问题蔓延的必要条件。
- 如果一个问题在一个版本中消失了，但在最新版本中又出现了，那么重现这个问题将是一项困难的任务。
- 微服务架构使得独立部署变得复杂。
- 微服务架构带来大量的操作开销。
- 当系统中添加新服务时，应用程序的管理会变得困难。
- 支持异构分布式微服务需要各种技能娴熟的专业人员。
- 微服务的成本很高，因为您需要为不同的业务任务维护不同的服务器空间。
SOA 与微服务
SOA 服务由组织内的注册中心维护，该注册中心充当服务目录列表。应用程序需要从注册中心查找服务并调用该服务。换句话说， SOA的 就像一个管弦乐队，每个艺术家都用自己的乐器演奏，而音乐总监则向所有人发出指示。
另一方面，微服务是一种面向服务的架构风格，它将应用程序构建成一系列不同的小型服务，而不是一个单一的软件或应用程序。微服务就像一个舞蹈团，每个舞者都是独立的，并且知道自己该做什么。因此，即使他们错过了某些舞步，也知道如何回到正确的顺序。以下是面向服务的架构 (SOA) 和微服务的详细比较。
| 参数 | SOA的 | 微服务 |
|---|---|---|
| 设计类型 | 在SOA中，软件组件以服务的形式暴露给外界供使用。 | 微服务是SOA的一部分，是SOA的一种实现。 |
| 依赖 | 业务单位相互依赖。 | 它们彼此独立。 |
| 软件大小 | 该软件体积比任何传统软件都要大。 | 在微服务架构中，软件的体积总是很小。 |
| 技术栈 | 与微服务相比，技术栈较低。 | 微服务技术堆栈可能非常庞大。 |
| 申请性质 | 本质上是整体式的。 | 全栈式结构。 |
| 独立与专注 | SOA 应用程序旨在执行多项业务任务。 | 它们是为执行单一业务任务而构建的。 |
| 部署 | 部署过程很耗时。 | 部署简单且耗时较少。 |
| 成本效益 | 更划算。 | Less 划算的。 |
| 可扩展性 | Less 与微服务相比。 | 高度可扩展。 |
| 商业逻辑 | 业务逻辑组件存储在单个服务域中，采用简单的网络协议（HTTP 和 XML 或 JSON），并通过 SDK/客户端驱动 API。 | 业务逻辑可以跨域存在，服务之间通过类似企业服务总线的层（中间件）进行连接。 |
微服务工具
1）Wiremock：测试微服务
WireMock 是一个灵活的库，用于模拟和模拟 Web 服务。它可以配置 HTTP API 在收到特定请求时返回的响应。它也常用于微服务测试。
下载链接： http://wiremock.org/
2）Docker
Docker 是一个开源项目，它允许我们使用容器来创建、部署和运行应用程序。通过使用这些容器，开发人员可以将应用程序作为一个单独的软件包运行。它允许您将库和其他依赖项打包在一个软件包中。
下载链接： https://www.docker.com/
3）Hystrix
Hystrix 是一种容错机制 Java 该工具旨在隔离分布式环境（例如微服务架构）中对远程服务、系统和第三方库的访问点。它通过隔离故障服务并防止故障的级联效应来改进整个系统。
下载链接： https://github.com/Netflix/Hystrix
微服务最佳实践 Archi质地
- 每个微服务都有独立的数据存储。
- 保持代码成熟度在相近水平。
- 每个微服务单独构建。
- 始终将每个服务器视为无状态服务器。
