小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

微服务

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

和单体应用架构的对比

单体应用架构是构建这样一个系统最自然的方式。处理请求的所有逻辑都运行在一个单一进程中，允许你使用编程语言的基本特性将应用程序划分类、函数和命名空间。你认真的在开发机上运行测试应用程序，并使用部署管道来保证变更已被正确地测试并部署到生产环境中。该单体的水平扩展可以通过在负载均衡器后面运行多个实例来实现。

单体服务器的问题

• 变更周期被捆绑在一起
• 即使只变更应用程序的一部分，也需要重新构建并部署整个单体。

长此以往，通常将很难保持一个良好的模块架构，这使得很难变更只发生在需要变更的模块内。程序扩展要求进行整个应用程序的扩展而不是需要更多资源的应用程序部分的扩展。

微服务架构风格

构建应用程序为服务套件。除了服务是可独立部署、可独立扩展的之外，每个服务都提供一个固定的模块边界。甚至允许不同的服务用不同的的语言开发，由不同的团队管理。

微服务架构的常见问题

一旦采用微服务系统机构，就会遇到这样几个问题

• 这么多小服务，如何管理? 服务治理、注册中心(服务注册、发现、删除)

• 这么多小服务，它们之间如何通信？restful、rpc、dubbo、feign

• 这么多小服务，客户端怎么访问他们？网关(gateway)

• 这么多小服务，一旦出现问题如何自处理？容错

• 这么多小服务，一旦出现问题如何排错？链路追踪