Apache Cassandra——可扩展微服务应用程序的持久数据存储

通过使用微服务，团队可以更快地响应变化，而无需改动整个应用程序。利用微服务，开发团队可以构建出具有鲁棒性和可扩展性的系统，从而适应当今应用程序的需求。

 

然而，使用微服务也带来了一系列挑战。在本文中，我们将就此展开讨论。

 

软件工程师和架构师正在远离基于单一、庞大的代码库的单体应用程序。由于公司需要在全球范围内运营，昼夜不停地开展业务，加上工作中对敏捷性和客户需求响应能力的要求也越来越高，因此对单体应用程序的管理和扩展变得越来越难。

 

微服务架构作为一种新的方式，其出现填补了这一空缺。企业的软件团队已经从他们的领域驱动设计(Domain Driven Design)经验中有所收获，并已经接受了持续集成和持续交付(CI/CD)有着帮助软件更高效地投入生产的能力。

 

通过使用微服务，团队可以更快地响应变化，而无需改动整个应用程序。他们提倡根据服务的生命周期组建小型团队，并示范了如何构建出具有鲁棒性和可扩展性的系统，以便适应当今应用程序的需求。

 

 

---

 

01 向微服务迁移

 

微服务方法是建立在以往的所有实践经验和技术基础之上的。

 

微服务是通过多个小型且相互独立的进程来建构复杂的应用程序的。这些进程之间通过像是REST这样与语言无关的轻量级应用程序接口（API）进行相互沟通。

 

将这些微服务分布到多个服务器或设备镜像上，再根据扩展需要对这些服务器进行复制——这样，这些服务就可以达到扩展的目的。

 

这些服务好比小型的建筑模块，它们高度解耦，专注于执行小块任务，并促进了系统构建的模块化。这每一个服务模块都是独立部署和独立管理的。像是容器这类的技术正在逐步成为创建此类服务的默认选择。

 

从现存的单体应用向微服务迁移，其过程包括将单体应用程序的任务划分为微服务架构所具有的不同且独立的服务。之后，所有的或大多数的功能都将在微服务架构中实现。

 

您可以根据业务逻辑、前端和数据访问来拆分单体程序。根据模块拆分单体应用程序后，它将逐渐缩小。之后当再需要新功能时，相比在单体程序中写入更多代码，我们可以通过创建微服务来实现这些功能。

 

独立运行服务有着以下这些明显优势：

• 适用于多种语言：只要服务的端点API返回所需的输出，您可以选择任何语言或技术来开发它。
• 部署的乐趣：微服务的独立性使其更易于部署。与单体应用程序不同，微服务更新或扩展组件时不需要使整个应用程序离线。
• 级联较少：同样，任何一项服务的故障都不会导致整个应用程序的级联故障。如果您没有遵循好的设计方法（例如Netflix方法），那么部分故障可能会出现，但是服务的独立性使得调试过程更加有针对性。
• 循环利用：一旦走上微服务之路，服务代码可以轻松地被重复利用到其它项目中。

---

 

02 微服务应用程序面临的挑战

 

微服务架构在带来一些显著好处的同时，也带来了一些挑战。通过应用正确的方法可以解决许多挑战问题。

 

从一开始，非常重要的是为服务选择正确的功能。为单体的每个功能都创建微服务会带来不必要的复杂性。微服务的目标是分解应用程序，以实现敏捷应用程序的开发和部署。微服务领域的领先思想者山姆·纽曼(Sam Newman)倡导了一条有用的经验法则，那就是，如果代码库太大而无法由一个小团队管理时，就应该考虑将其分解了。

 

同样，如果实施不正确，服务间通信的成本也会很高。您需要从消息传递和RPC等选项中选择成本最低的方法来满足需求。

 

例如，向客户通知他们的出租车或包裹即将到达的通知仅需要一对一的单向请求，而不是一对多的通知；之后，该通知期望在指定时间范围内得到答复。

 

另一个挑战是复杂性。部署微服务应用程序通常需要一个分布式环境，该环境可以跨多个环境运行，从数据中心的不同服务器到完全分布式的环境（如云）。

 

这些分布式环境随后将需要使用容器编排工具（例如Kubernetes）进行管理。仔细考虑好如何利用Kubernetes创建的新容器之类来实现流程自动化可以消除严重的扩展难题。

 

除此之外，您还必须考虑如何逐步测试和管理应用程序。由于涉及的服务与平台的数量之多及其相互依赖性，微服务端到端的测试可能具有挑战性。尽管面临各种挑战，您的应用程序复杂且多变，微服务仍将为您的企业不断效劳。

 

 

---

 

03 微服务和数据

 

除了应用程序的进程之外，对由此产生的数据进行分析也很重要。每个微服务可以是无状态的，也可以是有状态的。这意味着无状态的微服务不会在调用之间维护服务内的任何状态信息。该服务会接收请求，处理请求并发回响应，但不会保留任何状态信息以备将来调用。

 

有状态的微服务将以某种形式持久化以使其正常运行。使用微服务的系统通常会混合使用无状态组件和有状态组件——例如，用于更改文件的服务可能不需要随时保留该文件的副本，而客户服务应用程序的组件则会产生必须存储的数据。

 

当您需要状态信息时，不要把它放在内部存储；把它放在外部的数据存储中会更容易些。用于保留状态的数据存储类型将取决于您的需求以及随着时间的推移您预计产生的数据量。

 

您可以选择传统的关系数据库管理系统（RDBMS），NoSQL数据库或某种类型的云存储。在外部保留状态信息可以为之提供可用性，可靠性、可伸缩性和一致性。

 

对于产生大量数据的应用程序，如果这些数据要求被有效地编排组织，数据库通常比对象存储或云存储更好。对于涉及事务或客户服务的应用程序，规模性能也很重要。您可以了解一下NoSQL数据库（例如Apache Cassandra）可能在这方面提供的帮助。

 

由于Apache Cassandra可以通过添加节点来线性扩展，它已成为微服务应用程序中流行的持久数据存储选择。

 

例如，在Monzo公司，微服务和Cassandra的结合使得这个银行领域的挑战者每年都能将客户群增加四倍，而不会遇到任何问题。Monzo公司表示，在高峰时期，它可以在银行中现有的1,500种微服务中每秒处理300,000次读取，所有这些微服务都连接到其Apache Cassandra集群。

 

在微服务应用程序面临很多不定因素的情况下，支持该应用程序的任何数据库实施都必须能够轻松扩展并连接到所有组件。

 

使用Kubernetes之类的容器编排工具来管理应用程序和数据库实例可以实现这一点。使用Kubernetes Operator进行管理，在需要时添加数据库节点，可以避免扩展数据库方面的很多管理问题。

 

同样值得考虑的是数据一致性和弹性问题。在分布式计算环境中，可以重播丢失的消息并重新创建事务。

 

这在分布式数据库中并不是那么简单，因此需要研究如何处理数据一致性的问题。Cassandra根据Paxos原则和最终一致性进行处理——这确保了所有数据副本在每个节点上都是一致的。

 

对于需要ACID事务的应用程序，可能需要一个单独的数据库实例；对于绝大多数应用程序，数毫秒内即可达到的最终一致性是足够支持正常运行的。

 

 

---

 

04 微服务的未来

 

微服务可满足当今IT的需求。它们可以驻留在世界各地的多个数据中心环境中，也可以在混合云部署中实施，以提供足够的规模和对数据的即时访问。

 

这样就可以满足应用程序的需求，例如连续可用性和无延迟。考量微服务应用程序也意味着考量应用程序将产生的数据。

 

使用分布式NoSQL数据库可提供同样的应用程序设计方法——广泛分布、可伸缩并能够在多个环境中运行。同时考量应用程序设计和数据库设计将使您能够更加充分地享受微服务带来的好处。