1、web应用架构的发展历程
借用网图：
现代网络架构由最开始的三层mvc（单体架构）渐渐演变。一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。最初这种单体架构开发，开发速度快，成本低，但随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多，单体架构的应用并发能力十分有限。即便将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离，但代码的可读性和可维护性依然很差，并发能力也依然不足。
2、什么是微服务
基于SOA（面向服务开发的架构），渐渐产生了微服务架构，微服务可以说是SOA的一种升华，将复杂的业务组件化。微服务的架构的就是将项目拆分成各个子项目，进行解耦操作，提供外部访问接口。比如：把淘宝网订单系统，商品系统，购物车系统，账户系统，支付系统等等分成一个个不同的子项目，每一个子项目就是一个微服务。
微服务优点：
1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。
2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。
3）服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。
4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。
微服务带来的问题：
- 分布式系统的复杂性：
系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展。
- 部署，测试和监控的成本问题
对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护。
- 分布式事务和CAP的相关问题
原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高。