微服务架构是现代应用程序和系统的通用模型。其特点是将一个大型应用的业务职责划分为不同的、独立的组件，可以独立开发、管理、运营和扩展。微服务架构为扩展应用程序本身提供了一个有效的模型，允许更大、更分散的开发团队独立完成他们的部分工作，同时仍然参与更大应用程序的构建。在典型的微服务架构中，创建的单个服务包含特定的业务逻辑子集。当相互连接时，整套微服务就形成了一个完整的、大规模的应用，包含了完整的业务逻辑。这种模式非常适合代码，但数据呢？通常，为特定业务逻辑创建单独服务的公司觉得有必要将所有应用程序数据放入一个集中的数据存储中。这个想法是为了确保所有数据都可用于可能需要它的每个服务。管理单个数据存储简单方便，并且数据建模对于整个应用程序是一致的，无论使用它的服务如何。不要这样做，集中您的数据不是一个好主意。以下是三个原因：集中式数据难以扩展当整个应用程序的数据都在一个集中式数据存储中时，随着应用程序的增长，您必须扩展整个数据存储以满足应用程序中所有服务的需求。如图1左侧所示。如果为每个服务使用单独的数据存储，则只有需求增加的服务需要扩展，而被扩展的数据库是一个较小的数据库。这显示在图1的右侧。将小型数据库扩展到更大的大小比将大型数据库扩展到更大的大小要容易得多。图1.按服务对数据进行分区可简化缩放集中的数据。未来难以分割新应用程序的开发人员通常会想，“我现在不需要担心扩展问题，以后需要时再考虑”。这种观点虽然很常见，但有时会导致缩放问题。当应用程序变得流行时，您必须重新考虑架构决策以满足客户不断增加的需求。一个常见的架构变化是需要将您的数据存储拆分成更小的数据存储。问题在于，在应用程序首次创建时进行拆分比在应用程序生命周期后期进行拆分更容易。当应用程序已经存在数年并且应用程序的所有部分都可以访问相应的数据时，重要的是要确定数据集的哪些部分可以拆分为单独的数据存储，而无需对使用的代码进行重大重新设计数据。写作变得非常困难。即使是简单的问题也会变得困难。哪些服务正在使用配置文件表？是否有同时需要系统表和项目表的服务？而且，更糟糕的是，是否有任何服务使用这两个表来执行连接？它是做什么用的？代码在哪里完成？我们如何重构这个变化？数据集在数据存储中停留的时间越长，以后就越难将该数据存储分解成更小的部分。通过按功能将数据分离到单独的数据存储中，您可以避免以后将数据与联接表分离相关的问题，还可以减少代码中存在的数据之间意外关联的可能性。集中数据使数据所有权变得不可能将数据划分为多个服务的优势之一是能够将应用程序所有权划分为不同的、可分离的部分。单个开发团队拥有应用程序所有权是现代应用程序开发的核心原则，它可以在出现问题时促进更好的组织扩展和提高响应能力。此所有权模型在面向单一团队的服务架构(STOSA)开发模型中进行了讨论。当你有一个庞大的开发团队都在为一个大型应用程序做贡献时，这种模式非常有效，但即使是拥有较小团队的小型应用程序也可以从这种模式中受益。问题在于，团队要拥有服务的所有权，就必须同时拥有该服务的代码和数据。这意味着一个服务（服务A）不应直接访问另一个服务（服务B）的数据。如果服务A需要存储在服务B中的某些内容，它必须调用服务B的服务入口点之一，而不是直接访问数据。图2.服务A不应直接访问服务B的数据。这允许服务B对其数据、存储方式和维护方式拥有完全自主权。那么，有哪些选择呢？当您构建面向服务的体系结构(SOA)时，每个服务都应该拥有自己的数据。这些数据是服务的一部分并纳入服务。图3.每个服务都有自己的数据这样，服务的所有者可以管理服务的数据。如果需要对数据进行模式更改或其他结构更改，服务所有者可以在没有任何其他服务所有者参与的情况下实施更改。随着应用程序（及其服务）的增长，服务所有者可以做出扩展决策和数据重构决策来处理增加的负载和不断变化的需求，而无需其他服务所有者的参与。经常会出现一个问题，真正需要在应用程序之间共享的数据怎么办？例如用户配置文件数据，或许多应用程序中常用的其他数据。一个诱人的快速解决方案可能是仅共享跨多个服务所需的数据，如图4所示。每个服务可能有自己的数据，同时也可以访问共享数据。图4.不建议在服务之间共享数据。更好的方法是将共享数据放入一个新服务中，供所有其他服务使用，如图5所示。图5.使用服务是访问共享数据的正确方法服务C这个新服务也应该符合STOSA要求。特别是，它应该有一个单一的、定义明确的团队来拥有服务和共享数据。如果其他任何服务，如图中的服务A或服务B，需要访问共享数据，则必须通过服务C提供的API来访问。这样，服务C的所有者是唯一负责共享数据的团队并且可以就扩展、重构和更新做出适当的决定。只要为服务A和服务B维护一致的API以供使用，服务C就可以做出有关更新数据的任何决定。这与图4形成对比，其中服务A和服务B都直接访问共享数据。在此模型中，没有任何一个团队可以在不涉及直接访问数据的所有其他团队的情况下就数据的结构、布局、缩放或建模做出任何决策，这限制了应用程序开发过程的可扩展性。使用微服务或其他SOA是管理处理大型应用程序的大型开发团队的好方法。然而，服务架构还必须包括应用程序的数据，否则真正的服务独立性——即开发组织的扩展独立性——将不可能实现。作者：LeeAtchison是云计算和应用程序现代化领域公认的思想领袖。Lee在Amazon、AmazonWebServices(AWS)、NewRelic和其他现代应用程序组织的产品开发、架构、扩展和现代化方面拥有超过30年的经验。
