第2章 使用Spring Boot构建微服务
一个微服务架极采用了丌同癿方法来提供癿功能。具体来诪，微服务架极有以下特性：
有限的：微服务单一职责、范围有限。微服务拥抱Unix哲学：一个应用只不过是一个服务集合，每个服务做一件事，并且一件事情做得很好。
松耦合：一个微服务应用就是一个小服务集合，仅仅通过使用非专有的调用协议（例如，HTTP和REST），
不执行特定的接口相互作用。只要服务不改变接口，微服务的拥有者有比在传统的应用架构更多的自由来对服务进行修改。
分离的：微服务完全拥有自己的数据结构和数据来源。由微服务数据只能通过服务修改。
对数据库的访问控制使微服务的数据被锁定，仅允许这个服务访问它。
独立的：在微服务应用程序中的每个微服务，可以独立于应用程序中的其他服务被编译和部署。
这意味着与更为相互依赖的整体应用程序相比，更改可以更容易地隔离和测试。
2.1. 架构师的故事：设计微服务架构
在建立一个微服务架构的时候，一个项目的架构聚焦在三个关键任务：
分解业务问题
确定服务粒度
定义服务接口
分解业务领域是一种艺术形式，而不是一门黑白科学。使用下列准则确定和分解业务问题成为微服务候选者：
描述业务问题，依你用的名词来描述问题。在描述问题时反复使用相同的名词，通常是一个核心业务领域和一个微服务契机的象征。
从第1章癿EagleEye域目标名词的例子，看起来如：合同、许可证和资产。
注意动词。动词突出动作，通常表示问题域的自然轮廓。如果你发现自己在说“交易X需要从A和B类获得数据”，
那通常意味着有多个服务在起作用。如果你运用EagleEye看动词的方法，
你可能会寻找这样的语句，“当迈克使用桌面服务正在安装一台新电脑，他查看了可供软件X的可用许可证数量，如果许可证可用，安装软件。
然后，他更新跟踪电子表格中已使用的许可证数量。”这里的关键动词是looks和updates。
寻找数据内聚性。当你把你的业务问题分解成离散的部分时，寻找那些彼此高度相关的数据块。
如果突然间，在你人机对话的过程中，你正在阅读戒更新与你之前讨论过的根本不同的数据，
你可能会有另一个候选服务。微服务应该完全拥有自己的数据。
在图中，我突出显示了与业务用户对话期间出现的一些名词和劢词。
因为这是一个已有的应用程序，您可以查看应用程序并将主要的名词映射到物理数据模型中的表。
现有的应用程序可能有数百个表，但是每个表通常会映射到一组逻辑实体。
图2.2简化癿EagleEye数据模型
图2.2显示了一个在与EagleEye客户交谈的基础上简化的数据模型。
基于企业访谈和数据模型，候选微服务是组织、许可证、合同、资产服务。
2.1.2. 确定服务粒度
在将一个问题域分解为离散块之后，您常常发现自己在努力确定是否已经为服务实现了正确的粒度级别。
我们不久将讨论，一个微服务太粗或细会有一些明显的特征。
当你建立一个微服务架构、粒度的问题是重要的，但你可以用以下的概念来确定正确的解决方案：
首先关注您的服务如何与其它服务交互。这将有助于建立问题域的粗粒度接口。这使从太粗太细重构变得更容易。
（3）随着对问题域的理解不断增长，服务的职责将随着时间的推移而改变——通常来说，当需要新的应用功能时，微服务就会承担起职责。最初的微服务可能会发展为多个服务，原始的微服务则充当这些新服务的编排层，负责将应用的其他部分的功能封装起来。
糟糕的微服务的“味道”
如何知道微服务的划分是否正确？如果微服务过于粗粒度，可能会看到以下现象。
服务承担过多的职责——服务中的业务逻辑的一般流程很复杂，并且似乎正在执行一组过于多样化的业务规则。
该服务正在跨大量表来管理数据——微服务是它管理的数据的记录系统。如果发现自己将数据持久化存储到多个表或接触到当前数据库以外的表，那么这就是一条服务过于粗粒度的线索。我喜欢使用这么一个指导方针——微服务应该不超过3～5个表。再多一点，服务就可能承担了太多的职责。
测试用例太多——随着时间的推移，服务的规模和职责会增长。如果一开始有一个只有少量测试用例的服务，到了最后该服务需要数百个单元测试用例和集成测试用例，那么就可能需要重构。
如果微服务过于细粒度呢？
问题域的一部分微服务像兔子一样繁殖——如果一切都成为微服务，将服务中的业务逻辑组合起来会变得复杂和困难，因为完成一项工作所需的服务数量会快速增长。一种常见的“坏味道”出现在应用程序有几十个微服务，并且每个服务只与一个数据库表进行交互时。
微服务彼此间严重相互依赖——在问题域的某一部分中，微服务相互来回调用以完成单个用户请求。
微服务成为简单CRUD（Create，Read，Update，Delete）服务的集合——微服务是业务逻辑的表达，而不是数据源的抽象层。如果微服务除了CRUD相关逻辑之外什么都不做，那么它们可能被划分得太细粒度了。
应该通过演化思维的过程来开发一个微服务架构，在这个过程中，你知道不会第一次就得到正确的设计。这就是最好从一组粗粒度的服务而不是一组细粒度的服务开始的原因。同样重要的是，不要对设计带有教条主义。我们可能会面临两个单独的服务之间交互过于频繁，或者服务的域之间不存在明确的边界这样的物理约束，当面临这样的约束时，需要创建一个聚合服务来将数据连接在一起。
最后，采取务实的做法并进行交付，而不是浪费时间试图让设计变得完美，最终导致没有东西可以展现你的努力。
