微服务（Microservices）是一种软件架构风格。它以职责单一、细粒度的小型功能模块为基础，并将这些小型功能模块组合成一个复杂的大型系统。

早期的业务系统大多数单体服务，采用MVC架构，所有开发人员都在这个项目上开发，这种架构会带来哪些问题：

1. 模块耦合
   所有业务功能耦合在一起，时间一长依赖关系将会错综复杂，维护起来压力大。
2. 部署流程繁琐
   所有代码都在一起，部署需要确认所有功能，小的改动难以及时部署，排队上线成为日常，不利于敏捷开发。

微服务

• 微服务的优势

  • 开发效率高，维护更灵活

    • 各个服务可以独立部署，不需要再排队。

  • 更易扩容

    • 当请求量上涨导致系统负载过高时，只需对相应模块进行扩容，不需要对整个系统扩容。

• 微服务的缺点

  • 服务太多，难以调试

    • 服务A依赖服务B，服务B依赖服务C，测试时需要将所有服务都运行起来，如果涉及配置将更加繁琐。
    • 调用链过长，难以快速定位问题。

  • 延迟增加

    • 进程内处理变为序列化->网络传输->反序列化。如果网络传输成为瓶颈，可能导致系统延迟恶化。

  • 日志聚合与监控

    • 日志分散，检索变困难，需要新的手段将日志聚合起来。
    • 同时，监控也变得困难，需要分布式监控系统统一管理。

  • 数据一致性

    • 数据独立存储，数据库的事务不在工作，数据一致性将成为问题。

微服务的边界

说完微服务的优缺点后，如何进行微服务拆分是一个问题。设计微服务的一个原则是：高内聚、低耦合。和开发代码一样的。

1. 高内聚
   将一个功能模块的代码聚到一起，如用户、派单、支付。
2. 低耦合
   高内聚强调服务内部，低耦合强调服务之间。耦合高意味着一个服务改动，上下游都要跟着改。而耦合低，意味着服务的修改对上下游是无感知的。

微服务通信

微服务通信的选择有多种，从通信方式、传输协议、序列化方式都有不同的方案。

• 通信方式分为同步和异步。

  • 同步，就是阻塞等待服务器的返回。
  • 异步。可以通过回调函数、事件驱动等方式。常用的消息中间件有Kafka、RocketMQ、RabbitMQ。
• 传输协议有HTTP、gRPC、Thrift。
• 序列化方式有Json、Protobuf。

服务发现与负载均衡

传统的应用程序，下游的网络地址都是固定的，将ip地址写到配置文件即可。而微服务架构中，服务众多，服务可能动态的增加和销毁，地址也是动态分配的。因此要有灵活的服务发现机制，以便知道当前运行哪些服务。

1. 服务发现

• 服务注册。服务启动时在注册中心注册，同时通过心跳机制保持服务存活状态。即服务生产者。
• 服务发现。调用者通过注册中心获取服务提供者的可用节点列表。