一、为什么需要微服务架构？

1、单体应用架构介绍

我们都知道微服务做为一种架构的演进，肯定是由于在它出现之前的开发架构有问题不好解决，而它就是为了解决这些问题而出现的，所以只要我们弄清楚了架构的演进过程，其实也就弄清楚了这个问题。
微服务架构出现之前，大家都在使用是叫单体应用架构，这样的单体应用是构建系统最自然的方式，也就是常说的分层架构，但分层只是为了代码维护，最终还是会编译打包在一起，运行在同一个进程里面，运行请求流程如下图：

微服务简介 - 图1 所有处理请求的业务逻辑都在同一个服务端进程中，它允许你使用编程语言的特性来将整个应用划分为类、函数及命名空间。利用某些方法，你可以在笔记本电脑中运行和测试应用程序，并使用部署流水线确保新的更改通过了测试，并部署到了生产环境中。
这种方式也可以根据需要进行横向扩展，以便支持更多的请求，如下图所示：

微服务简介 - 图2 进行横向扩展后，需要在服务器前增加一个负载均衡，比如Nginx，用来统一接受请求，再根据一定的调度算法，将请求发到后端的服务器上进行处理，然后再将处理结果返回给浏览器。

2.单体应用架构存在的问题

1.更新周期问题

从上面的图中我们可以看出，单体应用最终是打包在一起，整体进行部署的，运行在同一个进程中。即使只是修改了很简单的一个功能，大部分功能都没有进行修改，也必须全部重新部署。

2.维护问题

单体应用包含那么多功能，为了提高开发效率，一般都会按功能进行分工，大家在各自的分支中增加和修改功能，但由于发布时必须将所有人的功能都集成在一起后进行发布，所以集成时可能会发生一些意想不到的问题。

3.隔离问题

由于核心业务和非核心业务都运行在同一个进程中，有时非核心业务的一些bug也会导致整个进程崩溃，让核心业务也受到影响，无法隔离这种错误。

4.扩展资源浪费问题

从上面的图中我们可以看出，要进行扩展时，必须将整体程序进行扩展，而程序里面包含所有的部分，可能有些是计算密集型的，有些是内存密集型的，但由于都在一起，所以就变成了服务器必须同时满足计算和内存的要求，不能按需扩展。

三、什么是微服务架构？

微服务架构是单体应用架构的一种演进，为了解决上述问题，所以他拥有以下特点：

按照业务来拆分服务，单个服务代码量小，业务单一，易于维护
每个微服务都有自己独立的基本组件，例如数据库、缓存等，且运行在独立的进程中
微服务之间的通信是通过轻松量级通讯协议（如HTTP协议，RPC协议）或者消息组件，且具有容错能力
微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务
单个微服务能够按需进行单独扩展，集群化部署
整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等
整个微服务系统有链路追踪的能力
有一套完整的实时日志系统

四、微服务是否是银弹？
不是的，他虽然解决了单体应用架构的问题，但同时也带来了新的问题和复杂度。
业务进行拆分后，会存在大量的小的服务，而这些服务都有自己独立的基本组件，如数据库，缓存。也需要独立部署。那么对这些服务的管理和监控就更复杂了
以前只有一个进程，一个数据库，数据库事务很容易保证，但拆分后，一个业务功能的实现，可能要好几个服务一起才能完成，此时业务数据的一致性需要考虑如何保证
一个业务功能的实现可能需要调用好几个服务来完成，那如果出错了，需要有很好的方法来跟踪出错信息，所以必须要增加链路追踪的能力，否则只会更糟糕
开发效率，由于微服务架构需要极强的一些基础组件，所以前期的开发效率会比单体架构慢一些，但随着业务复杂度的增加，单体架构的开发效率会极速下降，但微服务的开发效率只有少量下降，如下图所示：

所以建议可以先以单体架构开始，在业务复杂到一定程度后，再进行架构重构

自动化运维，对每个服务的运行状态的监控，单独扩展，服务的注册和发现等都应该是自动的，而不是由人工来进行
响应延时，原来一个功能到达后端后，都是在同一个进程内进行处理的，不存在进程间或者网络间的通信，但现在一个功能需要几个服务来完成，那服务间的通信可能会导致功能的整体响应时间的增加
网络放大问题，一个业务请求进来后，可能会需要再调用好几个服务模块来完成业务，一个请求就变成了好几个请求，这样对于服务之间的网络访问会放大，当流量很大的时候，这个问题特别要注意，否则很容易就直接将后面的服务直接冲垮
服务环依赖问题，服务之间可以互相依赖，但不能出现环依赖，比如A=>B=>C这样是可以的。但不能出现 A=>B=>A。
五、微服务的请求流程
六、微服务设计模式
1.聚合器