微服务学习笔记1微服务的大小微服务应该足够小，小到专注于某一个具体业务功能，也就是说首先应该保证每个微服务是具有业务独

微服务的大小

微服务应该足够小，小到专注于某一个具体业务功能，也就是说首先应该保证每个微服务是具有业务独立性的工作单元。在考虑微服务时，我们需要根据业务边界来确定服务的边界，这样就可以把该业务相关的内容都集中在微服务内部，从而体现了服务的高内聚性。

然而，我们还需要认识到服务过小可能带来的问题。服务越小，其独立性和高内聚性能够带来优势，但是也会导致服务数量太多，增加管理这些服务的成本。

微服务之间通过远程调用或消息传递的方式进行相互集成，能够提供松耦合的架构体系，每个微服务都可以在不影响其他微服务的前提下进行独立的修改、发布和部署。

微服务的大小和服务之间的交互方式构成了基本的微服务体系结构，分别代表了微服务高内聚、低耦合的基本特性。

服务组件化的主要目的是服务可以独立部署。

微服务架构下的划分方法倾向围绕业务功能的组织来分割服务。这些服务面向具体业务结构，而不是面向某项技术能力。

对具体的一个服务而言，应该根据业务上下文，选择合适的语言、工具进行构建。

团队使用微服务架构构建软件需要更广泛的依赖基础设施自动化技术。

组件化方案

使用微服务架构迫使我们使用诸如领域驱动设计的思想去进行策略设计和技术设计，从而为更好地划分业务功能、提取界限上下文和开展系统集成工作提供依据。

技术自由度

每个微服务高度独立，可以采用适合自身开发团队和技术体系的工具和框架来实现某个微服务，从而为我们提供了宝贵的技术自由度。

可扩展性

通过服务拆分和集成，单个服务在保持通信方式不变的前提下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响。

可伸缩性

当我们明确系统中的运行瓶颈，并把引起这些瓶颈的业务功能构建成独立的微服务，就可以应用服务集群等手段有效加强服务运行时的环境和状态。

支持持续交付

微服务作为独立的可部署单元，非常适合使用持续交付。微服务小而独立，一旦出现问题很容易进行回滚操作。

消除过程浪费

开发各自微服务的团队之间只需要进行较少的协调工作。微服务架构可以把大型团队打散成小型团队，而小型团队比大型团队具有更低的失败可能性。

微服务架构的一大特征就是根据业务来组建团队，某个特定业务局限于某个微服务中并由独立团队负责所有相关事宜。明确的边界有助于减少团队之间的扯皮现象，从而提升开发效率。

快速产品开发

将业务拆分成各个微服务能够让不同的业务功能处于一种并行开发的状态，因为每个团队所负责的业务需求只影响到团队自身的微服务，所以各个团队能够独立开发。

如果涉及简单业务需求的变更或者是发布部署的要求，独立的微服务之间也不需要太多的统一协调工作。