焦点报道:微服务设计原则

微服务架构在交付速度、故障隔离、整体的可用性、可扩展行以及资源成本方面有很大的优势，很多互联网公司在初期业务较少的情况下会优先选择单体架构，只有公司的当业务复杂度不断提升，微服务架构已经不能满足需求，微服务架构降低成本消耗的优势不断的显现出来，应逐步划分微服务架构，并持续演进。在服务划分之前，应该保证基础设施及公共基础服务已经准备完毕。可以通过监控快速定位故障，通过工具自动化部署、管理服务，通过服务化框架降低服务开发的复杂度，通过灰度发布提升可用性，通过资源调度服务快速申请、释放资源，通过弹性伸缩快速扩展应用。

那么在微服务架构的设计过程中，我们应该遵循哪些原则?

1.垂直划分优先原则

(资料图片)

众所周知，水平划分服务可能会出现因为频繁的调用次数增加，可能会造成性能下降，业务领域不同进行垂直划分，可以轻松实现一个功能可以跨越更多服务，降低沟通成本增加等问题，垂直划分服务可以以最简单的方式解决以上的问题，让团队更加关注业务实现，端到端负责，持续改进。如下图简单描述了一个按业务领域垂直划分的微服务架构示例，在业务垂直方向切分服务，通过 API Gateway 聚合内容。

2.持续演进原则

服务数量的增加可能会给开发、测试和运维等环节增加困难，可能带来架构的复杂度不断增加，可能造成故障率大幅增加，降低可用性。我们应该考虑逐步划分、持续良性演进，以减少服务数量突然增长带来的故障。如果出现故障，则可以减少故障的影响范围。另外，除了业务服务数量的增加，还需要准备持续交付的工具、微服务框架等，并加强监控。

3.服务自治、接口隔离原则

尽量减少对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。应该尽量避免直接访问对方的数据库会造的耦合性。

4.自动化驱动原则

部署与运维的成本会随着服务的增多呈指数级增长，每个服务都需要部署、监控、日志分析等运维工作，成本会显著提升。在服务划分之前，应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作，通过工具实现更可靠的操作。尽量避免因为微服务数量的不断增多给开发人员带来的各种问题。自动化可以从多个方面节省时间、提高效率，它可以快速跟踪整个交付过程并实时向所有参与者报告这个过程，赋予参与者责任感和成就感。如在研发过程中，推行持续集成的文化就特别重要，而持续集成所依赖的工具就是一种自动化的体现。

比如说开源的协作模式，微服务架构的设计原则更多倾向于自动化，自动化的模式针对跨地域研发优势更加明显，微服务架构更加敏捷地实现发布、更新和部署，每个微服务都可以独立开发，它们都有自己的代码库，由一个开发组开发、测试和部署，每个独立的微服务都有较好的容错性，一个微服务发生内存泄漏不会影响其他微服务。灵活性更强，与现有环境的集成代价更小，运维和管理成本更低。

关键词： 设计原则 开发人员 故障隔离