一、什么是微服务？

微服务是一种软件架构风格，软件架构风格大家常听到的比如说【事件驱动架构】、【客户端-服务器架构】、【分层架构】。对于微服务来说，每个服务都围绕着特定的业务功能进行设计，这些服务可以独立部署、扩展、管理。而这些服务之间通常使用一些轻量级的通信机制，如HTTP，RPC、消息队列等等进行服务之间的通讯。

微服务架构的设计目标是将大型复杂的应用程序拆分为更小、更易于理解和开发的部分，从而提高灵活性、可维护性和可扩展性。

二、为什么要做微服务？

其实对于微服务和大单体两种架构的总会引起不少争论。

• 有的人说大单体好，可以节省服务间的通讯消耗，可以降低理解成本等等。

• 有的人说微服务好，可以弹性伸缩，技术的多样性，独立部署等等。

总的来说，微服务架构通过提高灵活性、可维护性、可扩展性和可靠性，帮助我们更快的完成高质量的需求开发，帮助我们减少业务上的高耦合，使我们在面临线上致命bug时，不至于产生雪崩状况等等。

三、如何在微服务和大单体中进行抉择？

我认为有以下几点可以作为选择微服务的考量：

1. 复杂性和规模：当程序变得越来越复杂、规模越来越大时，微服务架构会更加适合。微服务允许将程序拆分为多个小型、独立的服务，每个服务专注于特定的业务功能，从而降低系统的复杂性。
2. 团队规模和组织结构：当团队规模较大或者需要多个团队同时开发和维护应用程序时，微服务架构可以提供更好的团队自治和独立部署的能力，从而加快开发速度和灵活性。
3. 技术多样性：当团队希望使用不同的技术栈和编程语言来开发不同的服务时，微服务架构可以提供更大的灵活性，每个服务可以选择最适合其需求的技术。
4. 弹性和可扩展性：当需要快速扩展和部署新功能时，微服务架构可以提供更好的弹性和可扩展性，每个服务可以独立进行水平扩展，而不影响整个应用程序。

在不满足上面这些考量时，肯定还是大单体来得快，减少了通讯损耗，不是所有的服务架构都适合使用微服务去做。

四、微服务的通讯方式

1. HTTP ：使用HTTP协议和RESTful API进行通信是微服务架构中最常见的方式之一。每个微服务暴露自己的API，其他微服务可以通过HTTP请求来调用这些API，完成数据交换，这种当时学习成本最低，应用也很广泛，但是就是常规的HTTP1.1交互太慢，影响整体服务的速度，如果量不大，还好，如果请求并发较大，这个是致命的。
2. RPC：RPC的意思是【远程过程调用】，是一种高效的通信方式，它允许一个微服务调用另一个微服务的方法，就像调用本地方法一样。RPC框架如gRPC、Thrift等可以我们帮助实现跨语言的远程调用，但是RPC本身并不是一种规范，而是一种通用的概念和编程模型。它有多种实现方式和协议，如gRPC使用的就是HTTP作为传输协议，但是RPC不仅限于HTTP协议，还可以使用TCP、UDP等等底层协议进行实现。
3. 消息队列：使用消息队列进行异步通信是一种常见的微服务通信方式。每个微服务可以向消息队列发送消息，其他微服务可以订阅并接收这些消息。这种方式解耦了微服务之间的通信，提高了系统的弹性和可伸缩性。常见的消息队列包括RabbitMQ、Kafka和RocketMQ等。
4. 事件驱动：事件驱动架构通过发布和订阅事件的方式实现微服务之间的通信。当某个微服务发生某个事件时，它会发布该事件，其他订阅了该事件的微服务将会收到通知并做出相应的处理。这种方式可以实现松耦合和异步通信，适用于需要实时处理和反应的场景。

五、总结一下

一般提到微服务都离不开DevOps、Docker和k8s，理解 微服务架构是核心，devops、docker和k8s是工具，是手段。

微服务对我们的思考，更多的是思维上的转变。上面说了这么多，其实微服务并不难，对于微服务架构： 技术上不是问题，意识比工具重要。

关于微服务的几点设计出发点：

1. 后台服务贯彻Single Responsibility Principle（单一职责原则）
2. 应用程序的核心是业务逻辑，按照业务或客户需求组织资源（这是最难的）
3. DevOps（持续集成、持续部署、持续交付）
4. Docker、Kubernetes （弹性工具）