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

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

 

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

 

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

 

微服务架构做为一种新的方式，其出现填补了这一空缺。企业的软件团队已经从他们的领域驱动设计(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数据库可提供一样的应用程序设计方法——普遍分布、可伸缩并可以在多个环境中运行。同时考量应用程序设计和数据库设计将使您可以更加充分地享受微服务带来的好处。