微服务设计的原则：IDEALS，而不是SOLID( 二 ) _微服务设计

我们没有试图在所有类型的服务客户机上强加相同的服务契约（使用规范模型），而是通过“分离接口”，以便每种类型的客户机都能看到它需要的服务接口。我们怎么做？一个突出的选择是使用API网关，它可以进行消息格式转换（message format transformation），消息结构转换（message structure transformation），协议桥接（protocol bridging），消息路由（message routing）等。一个流行的替代方案是BFF（Backend for Frontends）模式。在这种情况下，我们为每种不同类型的客户机提供了一个API网关，也就是通常说的，为每种客户机提供不同的BFF,如下图所示：

文章插图

三、可部署性几乎在整个软件历史上，设计工作都集中在与实现单元（模块）如何组织以及运行时元素如何交互相关的设计决策上。架构策略、设计模式和其他设计策略为在层中组织软件元素、避免过度依赖、为特定类型的组件分配特定的角色或关注点以及软件空间中的其他设计决策提供了指导。对于微服务开发人员来说，有一些关键的设计决策超出了软件元素。
作为开发人员，我们早就意识到将软件正确打包并部署到适当的运行时环境中的重要性。然而，我们从没有像今天的微服务那样关注部署和运行时监控。在这里称为“可部署性”的技术和设计决策领域已经成为微服务成功的关键。主要原因是一个简单的事实，即微服务显著增加了部署单元的数量。
因此，IDEALS中的D代表微服务开发者有责任确保软件及其新版本随时可以部署到环境中供用户使用。总之，可部署性包括：

配置运行时基础设施，包括容器、pods、集群、持久性、安全性和网络。
微服务的扩缩容，或者将他们从一个运行时环境迁移到另一个运行时环境。
加速提交+构建+测试+部署过程
减少版本升级时的停机时间
同步相关软件的版本更改
监控微服务运行状况，以快速识别和修复故障。

实现良好的可部署性
自动化是实现高效部署的关键。自动化包括明智的使用工具和技术，这是自微服务出现以来不断看到最大变化的领域。因此，微服务开发人员应该在工具和平台方面寻找新的方向。但总是质疑每一个新选择的好处和挑战。（这里可参考Thoughtworks技术雷达和软件架构与设计趋势报告）
以下是开发人员在任何基于微服务的解决方案中为提高可部署性而应该考虑的策略和技术列表：