一、什么是微服务
微服务是系统架构中的一个风格，它的主旨是将一个原本独立的系统拆分多个小型服务，这些服务都在各自的进程中运行。被划分的每一个小型服务都是根据系统中某一项或者某一耦合度高的业务构建起来的，并且每个服务都维护自身的数据、业务开发、自动化测试案例以及独立。由于有了轻量级的通信基础，所以这些微服务可以用不同语言来编写。
二、什么是单体架构?有什么优缺点？
在项目中，我们通常将需求分为三个部分：数据库、服务器处理、前端展示。如果这些需求都实现在了同一个应用中，那么这个项目就是单体架构的。在项目发展初期，由于所有的业务逻辑写在一个应用中，开发、测试、部署变得简单高效。但是，随着业务不断扩大、需求不断增多，代码会越来越臃肿，系统变得难以维护。试想，当只需要修改一个很小的功能时，由于所以功能模块都写在同一个应用，重新部署会影响其他功能正常运行。另外，当项目太过庞大臃肿时，系统优化也是一道难题。每个功能模块的并发量、使用场景、消耗的资源类型都不同，但是它们都在同一个应用中，这就使得我们对各个功能模块的容量很难做出评估，难以对个别模块进行优化。
三、微服务解决了单体结构带来的哪些问题？
微服务的出现解决了单体结构随着业务增长而日渐臃肿带来的难以维护的问题。微服务将一个系统的不同功能拆分为多个服务，每个服务都能独立开发和部署。每个服务的更新、拓展都不会影响到其他服务的正常运行。此外，微服务的独立部署还使得我们可以更准确地评估功能模块的性能容量。
四、微服务产生了哪些问题？
1) 增加运维的难度。
运维人员由原先运维单体系统的一个进程到维护微服务架构的诸多进程，这无疑增加了运维的难度，需要运维人员具备更好的技术。
2) 需定义好API。
微服务之间的通讯依赖于API，需要服务端和客户端定义好API，确保API可以在各个服务之间正常调用。API定义实质上依赖于选择哪种IPC（交互式定义语言）。如果使用消息机制，API则由消息频道（channel）和消息类型构成；如果选择使用HTTP机制，API则由URL和请求、响应格式构成。
3) 分布式带来的问题。
由于微服务运行在各自的进程中，只能通过通信来进行协作，所以分布式环境带来的问题都需要被考虑进去，比如分布式事务、网络延迟或异常、异步消息。
4) 接口如何升级。
假设一个场景，某服务端的API接口要进行大规模升级，会使得新旧版本不兼容。因为不能强制要求所有客户端都立刻进行更新升级，所以服务端在进行API升级后仍需支持旧版本客户端的请求。如果API定义为RESTful接口，可以通过URL传入版本号，服务器根据版本号再做相应处理。
5) 如何处理部分失败。
如果服务端无法响应请求，那么客户端就是阻塞，一直等待服务端响应。这不仅会占有系统资源，也会使得阻塞的客户端越来越多，从而导致系统崩溃。
解决的方案有超时策略、限制请求数上限、断路器模式等。