微服务设计原则

微服务开发的前提是各个微服务的划分，那么，划分这些微服务的依据是什么呢？一起来看看！

1. 业务单一原则

业务单一原则是拆分微服务的主要原则，它使得微服务的开发更加优雅、交付更加敏捷。在这一原则下，单个微服务模块只关注功能单一、有界限的业务逻辑。从而完成某个特定的功能。比如：

• 会员模块只完成会员注册、登录功能
• 认证模块只完成认证功能
• 授权模块只完成对资源的授权功能

这3个微服务模块组成会员的注册功能，实现对资源的认证和授权。即每个微服务可独立运行在自己的进程里，一系列独立运行的微服务模块共同构建起整个系统。

业务单一原则指导着微服务拆分的粒度大小。微服务的粒度是为服务开发中一个重点和难点，也是一个争论的焦点。是把粒度划分为最小，还是根据代码量的多少来控制粒度，又或在根据业务复杂度来控制粒度，并没有特定的标准，必须根据业务本身进行设计。在微服务的最初设计阶段就应该明确其边界，但一定要做到高内聚、低耦合。

2. 服务自治原则

服务自治是指，每个微服务都应具备独立的业务能力和运行环境，开发、测试、构建、部署都应该可以独立运行，包括存储的数据库也应是独立的，微服务是独立的业务单元，而不应该依赖其他的微服务，并应能与其他微服务高度解耦。

3. 轻量级通信原则

由于构成微服务系统的微服务数量众多，因此，微服务之间的通信机制应该是轻量级的。轻量级的通信机制应该具备以下两点。

• 体量较轻：通信的语言非常轻量。
• 能跨语言、跨平台：通信方式需要能跨语言、跨平台，这样每一个微服务都有足够的独立性，可以不受技术的限制。在微服务架构中常用的通信协议有：REST、RPC、AMQP、STOMP、MQTT等。

4. 接口明确原则

微服务之间存在调用关系，为了避免以后因为某个微服务的接口发生变化而导致其他微服务都需要调整，所以在设计之初就要让这些接口尽可能具有通用性和灵活性。

5. 弹性（容错性）设计原则

弹性几乎是所有系统的基本要求。在微服务系统忠，在依赖的服务宕机、网络连接出现问题时，应能自动隔离服务、限制使用资源，或者对服务降级，即系统具有自我波阿虎能力。

6. 自动化原则

微服务架构也面临着许多的挑战，我们最好提供一套自动化方案来解决这些问题，因为在复杂的微服务体系下，以人工方式来运维显然时不合理的。能够自动化的一定要实现自动化，应该用自动化和标准的方法来提高效率，降低成本。

6.1 自动化测试

在微服务架构中，测试是一个极为复杂的过程。自动化测试可以减轻测试的负担，并且能够保证大量的微服务模块正常工作。

6.2 自动化监控与管理日志

监控和管理日志是指，监控微服务的状态、快速定位异常或错误。在微服务架构中，这两个功能尤为重要，因为微服务实例数量庞大、服务间调用极为复杂。

• 监控功能主要包括监控服务的可用状态、请求流量、调用链、错误计数、服务依赖关系等内容，以便及时发现问题并解决问题。也可以根据监控状体来及时调整系统负载、过载保护等。从而保护系统的稳定性和可用性。
  • 微服务可用的监控，可以使用Spring Boot Admin组件
  • 熔断器机制可以使用Hystrix，它可以收集一且请求的基本信息，并提供现成的Dashboard将信息可视化
  • 性能监控和调用链路追踪可以使用Sleuth或Zipkin等
• 日志功能主要包括对微服务日志的收集、聚合、展现、搜索及报表。现在已经有很多好的解决方案了，比如商业解决方案Splunk、Sumologic，以及ELC这个开源产品。

6.3 持续集成和持续交付

持续集成是指，频繁地将代码集成到主干。这样可以迅速发现错误，防止分支过度偏离主干，从而实现快速迭代并保证软件质量。

持续交付是指，频繁地向测试人员和用户交付系统地新版本，以便进行测试和评审。

6.4 持续部署

持续部署是持续交付地下一个步骤，是指将通过地代码自动部署到生产环境中。自动化部署是减少发布和部署地难度、复杂性和繁琐程度地过程。现有很多成熟地解决方案，比如Jenkins+Fastlane（Jenkins能自动检测Git代码地上传，然后调用脚本代码）。