选择部署策略：
部署单体应用意味着运行一个或多个来自单个较大应用的相同副本。你通常会配置 N 个服务器（物理或虚拟），每台服务器上会运行 M 个应用实例。单体应用的部署并不总是那么简单，但它比部署微服务应用要简单得多。
微服务应用由数十甚至上百个服务组成。服务使用不同的语言和框架编写。每个服务都是一个迷你应用，有自己特定的部署、资源、扩展和监视要求。例如，你需要根据服务的需求为每个服务运行一定数量的实例。此外，必须为每个服务实例提供相应的 CPU、内存和 I/O 资源。更有挑战性的是尽管这些如此复杂，部署服务也必须要快速、可靠和具有成本效益。
单主机多服务实例模式
当使用此模式时，你可以提供一台（个）或多个台（个）物理主机或虚拟主机，并在每台（个）主机上运行多个服务实例。从多方面来讲，这是传统的应用部署方式。每个服务实例在一台（个）或多台（个）主机的标准端口上运行。你需要像照顾宠物一样照顾这些主机。
每个主机一个服务实例模式
- 1. 每个虚拟机一个服务实例模式
- 2. 每个容器一个服务实例模式
可以使用集群管理工具（如 Kubernetes 或 Marathon）来管理容器
- 3. Serverless 部署
要部署微服务时，需将服务打包成 ZIP 文件并将上传到 AWS Lambda。你还要提供元数据，其中包括了被调用用来处理请求（又称为事件）的函数的名称。AWS Lambda 会自动运行足够的微服务服务实例来处理请求。你只需根据每个请求所用时间和内存消耗来付费。当然，问题往往出现在细节上，你很快注意到了 AWS Lambda 的局限性。但作为开发人员的你或组织中的任何人都无需担心服务器、虚拟机或容器方面的任何问题 ，这非常有吸引力，足以令人难以置信。
重构单体应用为微服务：
应该逐步重构单体应用，而不是通过爆炸式重写来实现。你可以逐渐添加新功能，并以微服务的形式创建现有功能的扩展 —— 以互补的形式修改单体应用，并且与单体应用共同运行。随着时间推移，单体应用实现的功能量会慢慢减少，直到它完全消失或变成另一个微服务。这种策略类似于在 70 公里/小时的高速公路上维修一辆汽车，很有挑战性，但至少比尝试爆炸式重写的风险要小得多。
策略一：停止挖掘
当你的单体应用变得难以管理时，这是一个不错的建议。换句话说，你应该停止扩张，避免使单体变得更大。这意味着当你要实现新功能时，你就不应该向单体添加更多的代码。相反，这一策略的主要思想是将新代码放到独立的微服务中。
策略二：前后端分离
缩小单体应用的一个策略是从业务逻辑层和数据访问层拆分出表现层。一个典型的企业应用由至少三种不同类型的组件组成：
- 1. 表现层（Presentation Layer，PL）
处理 HTTP 请求并实现（REST）API 或基于 HTML 的 Web UI 组件。在有复杂用户界面的应用中，表现层通常存在大量代码。
- 2. 业务逻辑层（Business Logic Layer，BLL）
作为应用核心，实现业务规则的组件。
- 3. 数据访问层（Data Access Layer，DAL）
数据访问基础设施组件，如数据库和消息代理。
表现逻辑部分与业务和数据访问逻辑部分之间通常有一个清晰的界限。
业务层有由一个或多个门面组成的粗粒度 API，其封装了业务逻辑组件。这个 API 是一个天然边界，你可以沿着该边界将单体应用拆分成两个较小的应用。一个应用包含表现层。另一个应用包含业务和数据访问逻辑。分割后，表现逻辑应用远程调用业务逻辑应用。
策略三：提取服务
第三个重构策略是将庞大的现有模块转变为独立的微服务。每次提取一个模块并将其转换成微服务时，单体就会缩小。一旦你转换了足够多的模块，单体应用将不再是问题。它将完全消失，或者变得小到可以被当做一个服务看待。
优先考虑提取频繁更改的模块，也有可以优先考虑提取单体应用中相对耗资源的模块
标签：服务,策略,部署,单体,--,实例,应用 From： https://www.cnblogs.com/l-926/p/16592814.html