1. 为什么要微服务架构（Why）
原因：传统的应用架构不合理，产生了新的架构模式。
1.1 传统应用架构的主要问题（Problems）
当一个系统中包含A、B、C三个业务模块，通过监控程序发现A和B累计消耗系统资源的20%，C却要占用80%时，系统运行一段时间后，C业务将会成为系统的瓶颈，从而降低系统的性能。
1.2 解决传统应用架构的问题（Solutions）
一般来看，只需要复制同样一份程序，并部署到另一台服务器上，只不过多台服务器上方通过负载均衡器将应用进行“水平扩展”。当请求资源时，先经过负载均衡器，通过路由算法（如轮询或哈希），将请求转发到后面的具体应用服务器上，这种方式也被成为反向代理。
1.3 其他问题（Others）
- 系统资源浪费（1.1中提到的）
- 部署效率太低（如果修改代码，需要部署整个应用）
- 技术选型单一（只能用一种语言）
2. 什么是微服务架构（What）
2.1 概念
应用满足一下要求，具体：
- 根据业务模块划分服务种类
- 每个服务可独立部署且项目隔离
- 通过轻量级 API 调用服务
- 服务需保证良好的高可用性
2.2 微服务交付流程
使用微服务架构开发应用，实际上是对一个个微服务进行设计、开发、测试、部署，每个服务之间没有彼此依赖。
3. 微服务有哪些特点和挑战
3.1 特点
- 微小度颗粒（根据业务功能来划分）
- 责任单一性
- 运行隔离型（每个服务相互隔离，且互不影响）
- 管理自动化
3.2 挑战
- 运维要求较高（自动化技术来部署，对微服务进行有效的监控，保障系统的高可用性）
- 分布式复杂性（微服务本质是一个分布式架构，对分布式系统而言，网络延迟，系统容错，分布式事务）
- 部署依赖较强（业务复杂的情况，可能多个服务来共同完成一件事，服务之间没有相互调用，但可能会有调用的顺序性要求）
- 通信成本较高（服务是隔离在自己的进程中运行的，从客户端调用微服务，需要跨进程进行调用，而进程间一定比进程内的调用更消耗资源，带来通信成本上的开销）
4. 如何搭建微服务（How）
4.1 微服务技术选型
使用 Spring Boot 作为微服务开发框架，其拥有嵌入式 Tomcat，可直接运行一个jar包来发布微服务，在发布微服务是，可连接ZooKeeper来注册微服务，实现“服务注册”。实际上ZooKeeper中有一个名为ZNode的内存树桩模型，树上的节点用来存放微服务的配置信息。使用Node.js处理浏览器发送的请求，在Node.js中连接ZooKeeper，发现服务配置，实现“服务发现”。通过Node.js将请求转发到Tomcat上，实现“反向代理”。此外，Node.js原生也提供了集群特性，可确保高可用性。为实现微服务自动化部署，可以通过Jenkins搭建自动化部署系统，并使用Docker将服务容器化封装。
1）使用Jenkins部署服务
2）使用Spring Boot 开发服务
3）使用Docker封装服务
4）使用ZooKeeper注册服务
5）使用Node.js调用服务
Spring官方在Spring Boot的基础上，封装了Netflix相关组件，提供一个名为Spring Cloud 的开源项目。