微服务概念

微服务

微服务是什么

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.-- James Lewis and Martin Fowler

引用来自https://www.martinfowler.com/articles/microservices.html

简言之，微服务架构风格是一种将单个应用程序开发为一套小型服务的方法，每个服务都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）通信。这些服务是围绕业务能力构建的，并通过完全自动化的部署机制进行独立部署。这些服务的集中管理是最低限度的，可以用不同的编程语言编写，并使用不同的数据存储技术。

总结：

1. 一些列的独立的服务共同组成系统
2. 单独部署，跑在自己的进程里
3. 每个服务为独立的业务开发
4. 分布式的管理

微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

分布式和微服务的区别

分布式是一种系统设计范式，强调多个独立节点通过网络通信协同工作。

微服务是一种软件架构风格，将应用拆分为小型、独立的服务，强调服务的独立性和快速部署。

分布式系统关注整体系统的设计，而微服务更专注于服务的独立性和灵活性。

微服务是一种实现分布式系统的方式，强调服务之间的松耦合和独立开发、部署的优势。

微服务的优缺点

优点：

1. 松耦合：每个微服务都是相对独立的单元，修改一个服务不会影响其他服务。
2. 独立部署：每个微服务可以独立开发、测试、部署和扩展，提高了开发和部署的速度。
3. 灵活性：使用不同的技术栈和编程语言来实现不同的服务，选择最适合特定任务的工具。
4. 可伸缩性：每个服务都可以独立扩展，允许对系统的不同部分进行水平扩展。
5. 容错性：如果一个服务发生故障，不会影响整个应用的稳定性。
6. 技术多样性：团队可以选择最适合他们技能和需求的技术，不受整体架构的限制。

缺点：

1. 复杂性：微服务架构引入了分布式系统的复杂性，需要解决分布式通信、一致性、监控等问题。
2. 部署和运维：管理大量微服务的部署和运维是挑战，需要适当的自动化和工具支持。
3. 数据一致性：微服务中的数据可能分布在不同的数据库中，确保数据一致性是一个复杂的问题。
4. 调试和测试：在微服务架构中，跨服务的调试和测试可能更加复杂，需要适当的工具和流程。
5. 通信开销：微服务之间的通信可能引入额外的开销，特别是在跨网络较远的情况下。
6. 服务间集成：确保微服务之间的良好集成和通信是一个关键问题，可能需要使用API网关等工具。

如何拆分微服务

• 业务能力：将不同业务功能模块拆分成单独的微服务，例如电商系统可以拆分为商品服务，订单服务，用户服务等等微服务。
• 团队架构：根据康威定律，组织架构决定系统架构，所以微服务在拆分的时候也应该关注团队的组织架构然后进行拆分，尽量减少沟通成本，提升开发效率。
• 应用类型：例如有些业务处理离线数据业务，这部分可以与在线业务进行拆分，减轻在线业务的压力。
• 技术栈：若团队使用了不同语言技术栈等，也可以考虑通过技术栈来拆分微服务。

CI/CD

CI/CD 是软件开发领域中的一种持续集成（Continuous Integration）和持续交付/持续部署（Continuous Delivery/Continuous Deployment）的实践方式。

1. 持续集成（Continuous Integration，CI）：是指开发者将代码集成到共享仓库中，并通过自动化的构建和测试流程，尽早发现和解决集成问题。
   • 目标：确保开发团队的代码持续地被集成，减少集成问题的发现时间，提高代码的质量。
2. 持续交付（Continuous Delivery，CD）：是在通过持续集成得到的构建通过一系列的自动化测试后，将软件部署到预生产环境，使其随时可供交付。
   • 目标：自动化构建、测试和部署过程，确保软件在任何时候都能够交付。
3. 持续部署（Continuous Deployment，CD）：即自动将通过测试的软件部署到生产环境，实现全自动化的部署流程。
   • 目标：在通过自动化测试的情况下，将软件的变更直接推送到生产环境，减少人工干预，提高交付速度。

蓝绿部署和金丝雀部署

蓝绿部署

在蓝绿部署中，有两个环境：蓝色环境（Blue）和绿色环境（Green）。当前正在运行的版本在一个环境中，而新版本在另一个环境中。

过程：首先，新版本在绿色环境中进行部署和测试。一旦测试通过，流量被切换到绿色环境，原先的蓝色环境变成备份。这样，可以随时切回原先的环境，降低了发布新版本的风险。

金丝雀部署(灰度发布)

金丝雀部署是逐步将新版本引入生产环境，只将新版本的一小部分流量引导到新的版本上，以测试其在真实环境中的性能和稳定性。

过程：开始时，只有少量用户（金丝雀用户）看到新版本。通过监控性能和错误率等指标，逐渐扩大新版本的流量份额，直至全部流量都切换到新版本。