本文要点
- 尽管微服务架构（MSA）有很多好处，但管理数百个松耦合的微服务很快就会变得很麻烦。这就是设计基于单元格的架构（CBA）的原因。
- CBA是一种微服务架构模式，它的主要要求是将多个微服务（及其他组件）分组成称为单元格的构建块，以方便管理和重用。
- 从零开始在容器编排平台上创建CBA很费力。在撰写本文时，Kubernetes是业界广泛采用的容器编排平台；然而，使用YAML编写用于此目的的Kubernetes工件并不是一项简单的任务。
- Cellery遵循代码优先的方法，处理实现CBA的底层复杂性。
- Cellery包含一个SDK、一个运行时和一个管理框架。
Cellery简介
Cellery到底是什么，它如何帮助我们在Kubernetes上部署和管理应用程序？Cellery是一种在Kubernetes上构建、集成、运行和管理复合应用程序的代码优先方法。这种复合应用程序的构建块称为单元格——其名称为Cellery，而不是Celery。为了帮你理解单元格和Cellery，让我们看看如何使用Cellery部署、管理和观察一个已有的由谷歌编写的Kubernetes应用程序。但是，在此之前，让我们先了解下单元格是什么以及单元格的工作原理。
单元格是什么？
让我们看一下，为什么需要在微服务架构中使用复合组件。
微服务是构建复杂且不断演化的应用程序的热门选项，它可以缩短上市时间，加快创新速度。每个服务都可以由专门负责该服务的团队独立开发，并且他们可以自由选择任何他们认为合理的技术。最重要的是，微服务是可重用的，每个服务都可以独立伸缩，使团队可以使用最能满足服务资源需求的最佳部署基础设施。开发人员可以对其服务进行本地更改，并在测试完成后立即部署这些更改。那么，这有什么挑战吗?
微服务（包括无服务器函数）的使用正在快速增长，因为组织的目标是提高开发速度和可伸缩性，而且它们还必须调整为面向业务能力的团队。在拥有数十个或数百个应用程序的企业中，管理如此多的松耦合微服务，不仅会成为运营的噩梦，也在团队沟通以及服务发现、版本控制和可观察性等方面提出了挑战。更多的服务、更多的沟通路径、更复杂的网络安排以及更多的潜在故障区。这就有了对高级结构的需求，将多个微服务和无服务器函数聚合到易于管理和重用的构建块中。
基于单元格的架构是一种微服务架构模式，它将系统的微服务、数据和其他功能组件（包括前端应用程序、遗留服务、代理、网关和遗留系统适配器）分组为内聚的、可单独部署的架构单元（称为单元格）。