这篇文章的目的是了解微服务、相关软件架构、设计原则和开发微服务时要考虑的约束。
1.微服务
微服务是小型自治系统，可提供在生态系统中独一无二的独特解决方案。它作为全栈模块运行，并与生态系统中的其他微服务协作。山姆·纽曼 (Sam Newman) 在他的《构建微服务》一书中将微服务定义为“小、专注并且把一件事做得很好”。
微服务是通过将单个大型整体系统切片和切块为许多独立的自治系统而创建的。它也可以是一个可插入的附加组件，作为一个新组件或作为一个新项目与现有系统一起工作。
2. 生态系统
尽管微服务的概念并不新鲜，但云技术、敏捷方法、持续集成和自动供应 (Dev Ops) 工具的发展导致了微服务的发展。
2.1 云技术
云的重要特征之一是“弹性”。云允许用户通过动态增加或减少虚拟机、存储、数据库等基础设施资源来动态地扩大和缩小系统的性能和容量。如果软件是一个单一的大型单片系统，它不能有效地利用云基础设施的这种能力，因为跨系统的内部子模块和通信管道可能是瓶颈，无法适当扩展。
由于微服务是小型、独立的全栈系统，它可以有效地利用云基础设施的弹性特性。通过增加或减少微服务实例的数量，将直接影响系统的性能和容量。
2.2 开发运营
Dev Ops 是一种专注于加快软件开发到客户部署过程的方法。这种方法专注于通过集成、自动化和合作来改善软件开发和 IT 运营之间的沟通和协作。
微服务架构支持满足软件工程师和 IT 专业人员的目标。与大型整体架构相比，作为小型独立组件，开发、测试、部署和恢复（如果失败）相对容易。
2.3 敏捷方法论
敏捷是从极限编程（XP）和迭代增量（2I）开发过程模型演变而来的软件开发过程模型。敏捷最适合从事软件交付工作的小型团队，在这些团队中，需求的波动性很高且上市时间较短。
根据敏捷宣言，敏捷更喜欢：
- 流程和工具的 个人交互
- 综合文档之上的 工作软件
- 合同谈判中的 客户协作
- 响应变化 胜于遵循计划
一个在敏捷过程模型中工作的小型动态团队开发一个小型、独立和全栈应用程序的微服务将拥有完整的产品所有权和明确的责任边界。
3. 微服务设计
3.1 微服务的特点
微服务被设计成小型的、无状态的、独立的和全栈的应用程序，以便它可以部署在云基础设施中。
小 ：微服务被设计成小的。但是定义“小”是主观的。可以使用一些估计技术，如代码行、功能点、用例。但它们不是敏捷中推荐的估算技术。
在 《Building Microservices》 一书中，作者 Sam Newman 建议了一些技术来定义微服务的大小，它们是：它应该足够小，可以由一个小型敏捷开发团队拥有，可以在一两个敏捷冲刺（通常是两到四个星期）或复杂度不需要重构或需要进一步划分到另一个微服务。
无状态 ：无状态应用程序使用仅包含在其中的信息处理每个请求。微服务必须是无状态的，并且它必须在不记住来自外部系统的先前通信的情况下为请求提供服务。
In(ter)dependent： 微服务必须独立地为请求提供服务，它可以与生态系统中的其他微服务协作。例如，在与其他微服务交互后生成唯一报告的微服务是一个相互依赖的系统。在这种情况下，其他仅向报告微服务提供必要数据的微服务可能是独立服务。
全栈应用程序： 全栈应用程序可以单独部署。它有自己的服务器、网络和托管环境。业务逻辑、数据模型和服务接口（API/UI）必须是整个系统的一部分。微服务必须是全栈应用。
3.2 架构原则
尽管 SOA 是有助于设计微服务的重要架构风格之一。在设计微服务时，需要考虑的架构风格和设计原则很少。他们是：
3.2.1 单一职责原则（ Robert C Martin ）
每个微服务都必须负责特定的特性或功能或内聚功能的聚合。应用这一原则的thump rule是：“聚集那些因相同原因而变化的事物，分离那些因不同原因而变化的事物”。
3.2.2 领域驱动设计
领域驱动设计是符合面向对象方法的架构原则。它建议设计系统以反映现实世界的领域。它考虑了业务领域、元素和行为以及业务领域之间的交互。例如，在银行领域，可以设计单独的微服务来处理各种业务功能，如零售银行、在线银行、在线交易等。零售银行微服务可以提供与之相关的服务，例如。银行开户、提现、存款等。
3.2.3 面向服务的架构
面向服务的架构 (SOA) 是一种架构风格，它强制执行某些原则和哲学。以下是在为云设计微服务时要遵守的 SOA 原则。
3.2.3.1 封装
服务必须封装内部实现细节，这样外部系统使用服务就不用担心内部。封装降低了复杂性，增强了系统的灵活性（适应变化）。
3.2.3.2 松耦合
一个微系统的变化对生态系统中的其他服务的影响应该为零或最小。该原则还建议在微服务之间采用松散耦合的通信方法。根据 SOA，RESTful API 比 Java RMI 更合适，后者在其他微服务上实施了一项技术。
3.2.3.3 关注点分离
基于与其他功能零重叠的独特功能开发微服务。主要目标是减少服务之间的交互，使它们高度内聚和松散耦合。如果我们跨错误的边界分离功能，将导致服务之间的紧密耦合和复杂性增加。
SOA 的上述核心原则仅提供了 SOA 的要点。 SOA 的更多原则和哲学非常适合云微服务的设计原则。
3.2.4 六边形架构
这种架构风格是由 Alistair Cockburn 提出的。它允许应用程序同样由用户、程序、自动测试或批处理脚本驱动，并在独立于其最终运行时设备和数据库的情况下进行开发和测试。这也称为“端口-适配器架构”，其中端口和适配器封装核心应用程序以一致地响应外部请求。端口和适配器处理外部消息并将它们转换为内部核心应用程序公开的适当函数或方法。典型的微服务公开用于外部通信的 RESTful API、用于事件通知的消息代理接口（例如 RabbitMQ、HornetQ 等）和用于持久性的数据库适配器使得六边形架构成为最适合微服务开发的样式。
尽管有许多架构风格和原则，但上述项目与微服务高度相关。
4 设计约束
设计约束（非功能性需求）是设计微服务时的重要决策者。系统的成功完全取决于可用性、可扩展性、性能、可用性和灵活性。
4.1 可用性
可用性的黄金法则说，预测故障并进行相应的设计，以便系统的可用性达到 99.999%（五个九）。这意味着系统在一整年内只能停机 5.5 分钟。集群模型用于支持高可用性，它建议让一组服务以 Active-Active 模式或 Active-Standby 模式运行。
所以在设计微服务时，必须设计合适的集群和高可用模型。微服务的无状态、独立和全栈等基本属性将帮助我们以双活或双活模式并行运行多个实例。
4.2 可扩展性
微服务必须能够水平和垂直扩展。由于可以水平扩展，我们可以拥有多个微服务实例来提高系统的性能。微服务的设计必须支持横向扩展（scale-out）。
此外，微服务应该可以垂直扩展（缩减）。如果微服务托管在具有中等配置的系统中，例如 AWS EC2 t2-small（1 核，2 GB 内存）移动到 M4 10x-large（40 核和 160GB 内存），它应该相应地扩展。同样，缩小系统容量也必须是可能的。
4.3 性能
性能通过吞吐量、响应时间（例如 2500 TPS - 每秒事务）来衡量。性能要求必须在设计阶段本身的开始就可用。有一些技术和设计选择会影响性能。他们是：
- 同步或异步通信
- 阻塞或非阻塞 API
- RESTful API 或 RPC
- XML 或 JSON ，选择
- SQL 或 NoSQL
- HornetQ 或 RabbitMQ
- MongoDB 或 Cassandra 或 CouchDB
因此，必须采取适当的技术和设计决策，以避免后期返工。
4.4 可用性
设计的可用性方面侧重于向最终用户或其他系统隐藏内部设计、架构、技术和其他复杂性。大多数时候，微服务将 API 公开给最终用户以及其他微服务。因此，API 必须以规范化的方式设计，以便以最少的 API 调用次数轻松实现所需的服务。
4.5 灵活性
灵活性衡量对变化的适应性。在微服务生态系统中，每个微服务由不同的团队拥有并以敏捷方法开发，变化将比任何其他系统更快地发生。如果微服务不适应或适应其他系统的变化，它们可能无法互操作。因此，必须有适当的机制来避免这种情况，包括发布 API、记录功能更改、明确的沟通计划。
这简要总结了微服务的重要设计约束。
5. 新问题空间
尽管微服务有许多积极因素，但它也会带来一些新的挑战。
5.1 完成功能测试
端到端的功能测试在微服务环境中将是一个巨大的挑战，因为我们可能需要部署许多微服务来验证单个业务功能。每个微服务都可能有自己的安装和配置方式。
5.2 整个生态系统的数据完整性
微服务系统独立且异步运行，它们通过适当的协议或 API 相互通信。这可能会暂时导致数据完整性问题或由于故障而导致不同步。所以我们可能需要额外的服务来监控数据完整性问题。
5.3 增加的复杂性
当一个整体被拆分成十到二十个微服务并且将负载平衡服务器、监控、日志记录和审计服务器引入生态系统时，复杂性会增加很多倍，这会增加运营开销。此外，管理和部署微服务所需的能力也变得非常关键，IT 管理员和 DevOps 工程师需要了解独立敏捷开发团队使用的大量技术。
文章 “微服务——不是免费的午餐！” 面向服务的架构 清楚地警告我们要注意微服务的问题，尽管他们非常支持和青睐这种架构风格。
6.总结
微服务架构风格有很多优点，我们讨论过它最适合云基础架构，加速部署和恢复，最大限度地减少故障时的损失。本文整合了设计微服务所需的设计、架构和设计约束方面的知识领域。谢谢。