16、应用扩展与内部服务搭建

应用扩展与内部服务搭建

1. 微服务架构

在构建应用时，一种可采用的方式是将服务拆分为多个服务，也就是使用微服务架构。此方法主要是创建多个内部服务来执行不同任务，并通过远程过程调用（本质上是 HTTP 请求）让其他服务调用这些功能。这与将完整程序逻辑置于单个容器中的单体服务设计方法形成对比。

将单体服务拆分为多个较小服务有好处也有弊端，所以不建议仅仅为了使用微服务架构而拆分。好处包括：
- 每个服务可使用不同编程语言。
- 各服务能独立开发（例如由不同团队负责）。
- 可进行独立扩展。

弊端包括：
- 调试和集成测试更复杂，因为组件增多，需要追踪系统中的请求。

关于应构建微服务还是单体服务，有两种观点可供参考：
- David Heinemeier Hansson（DHH）认为微服务适合大型科技公司，多数小团队采用单体服务更佳。他觉得微服务虽在某些情况有优势，但并非总是清晰明确，尤其是对小团队而言，其开销不值得。
- James Lewis 和 Martin Fowler 在文章中对微服务给出了深思熟虑且平衡的观点。其中一个突出的好处是产品思维，内部团队专注于构建和管理自己的组件，这种去中心化方法让团队能自主做架构决策。

如果有多个服务，就可对其分别进行扩展。例如，有一个主要处理 HTML 和 JSON 请求的 Web 应用，但有一个端点进行实时图形处理，其内存使用量高于普通请求。此时创建一个单独的 Deployment（即使使用相同容器）来处理该图形端点是值得的，这样既能单独扩展它，还能使其与其他部分隔离。

实现方式有两种：
- 可使用单个前端调用内