微服务架构实战笔记

1.更简单：通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。2.自由选型：这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务3.部署独立：微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响4.服务独立扩展:你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。1.微服务强调了服务大小：拆太小？2.微服务应用是分布式系统，由此会带来固有的复杂性：开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必 微服务架构是一种现代软件开发和部署的模式，它提倡将大型的单体应用程序分解为一组小型、独立的服务，每个服务专注于特定的业务功能，并能够独立地开发、部署和扩展。这种架构模式带来了诸多优势，同时也伴随着一些挑战。 优势： 1. **更简单的管理**：微服务架构通过拆分大型应用，将复杂性分散到多个服务中，每个服务都可以作为独立的单元进行管理和维护，从而降低整体复杂性。 2. **技术选型自由**：每个服务可以由不同的开发团队使用最适合的技术栈来构建，提供了更多的灵活性和创新空间。 3. **独立部署**：每个服务都可独立部署，不会因为其他服务的更新而影响到已部署的服务，加速了交付周期。 4. **弹性伸缩**：可以根据每个服务的实际需求，独立扩展服务的实例数量，以适应不同负载，提高资源利用率。 然而，微服务架构也存在一些不足： 1. **服务大小的权衡**：微服务强调服务的粒度要适当，太小可能导致管理过于复杂，太大则失去微服务的意义。 2. **分布式系统的复杂性**：微服务是分布式系统，涉及到服务间的通信问题，如RPC或消息传递，需要处理分布式环境下的故障恢复和一致性问题。 3. **分布式事务**：处理跨服务的事务一致性是微服务的一大挑战，需要采用补偿事务或其他解决方案。 4. **测试难度增加**：测试微服务需要模拟所有相关的服务，增加了测试的复杂性。 5. **变更传播**：修改一个服务可能会影响到多个依赖它的服务，需要协调多团队的开发工作。 6. **部署复杂性**：微服务应用通常由大量服务组成，部署和配置管理变得更为复杂。 在实际应用中，微服务架构的客户端直接通信问题也是需要解决的关键问题。客户端需要与多个微服务交互，可能导致过多的网络请求，影响性能，特别是在移动网络环境下。为此，引入了**API Gateway**的概念。 API Gateway作为一个集中式的入口，它负责将客户端请求转发至相应的微服务，同时执行聚合、转换协议等功能，减轻客户端的压力。它还能够实现统一的认证、监控、负载均衡和缓存策略。API Gateway允许系统内部使用非Web友好的协议，而对外只暴露简洁的HTTP或WebSocket接口，提高了系统的对外兼容性和安全性。此外，API Gateway可以随着系统演进，适应服务的合并与拆分，简化重构过程。 以Netflix为例，其API Gateway处理了大量跨平台的请求，通过调用多个后端服务来提供定制化、高可用性的API。尽管API Gateway带来了诸多好处，如简化客户端交互和优化性能，但它也会引入新的复杂性，如增加系统的单一故障点，并可能需要更高的计算和存储资源来运行。因此，在设计和实现API Gateway时，需要权衡这些因素，确保其有效支持微服务架构的高效运行。