7、微服务采用框架：从单体架构到云原生微服务

微服务采用框架：从单体架构到云原生微服务

1. 单体架构与微服务架构对比

在互联网时代之前，单体架构是应用开发的默认选择。单体架构的应用开发、测试、部署相对容易，甚至可以进行水平扩展。然而，单体架构存在诸多问题。由于其功能相互依赖，很难独立处理单个功能。哪怕是一个小的更改，都需要将整个应用下线。而且，在单体应用中，很难理清哪段代码控制着哪个功能。

单体应用通常有分层设计，如展示层、业务层和数据访问层。虽然这种架构听起来不错，但它仍然是一个单一的应用。要进行任何大的更改，都需要重新部署整个应用。

REST（表述性状态转移）是一种基于HTTP的软件架构风格，常用于开发允许不同应用通过互联网相互通信的Web服务。REST API通常使用HTTP方法（如GET、POST、PUT、DELETE等）对Web服务器执行操作，可返回多种格式的数据。

与之相对，微服务架构将应用拆分为多个功能（微服务），可以独立开发每个组件，从而提高软件开发速度和上市时间。微服务通常由API层、计算资源和数据存储组成，可以进行扩展或利用开源服务。微服务架构能让系统适应不断变化的业务需求，在复杂的系统网络中，当系统和应用变得过于庞大和复杂时，微服务架构尤为有益。

2. 从单体架构转向微服务架构的策略

2.1 打破单体架构：构建微服务设计的策略

• 确定服务边界 ：在拆分单体应用之前，需要了解应用的结构和不同功能的位置，确定服务边界，然后将其拆分为更小的独立服务。
• 重组团队 ：随着单体应用拆分为微服务，需要相应地重组团队，创