第一章 应用架构演进
1.传统垂直应用架构
（1）简介：
在2006年之前，业界比较流行的有LAMP架构，MVC架构，EJB企业架构
LAMP：Linux+Apache+PHP（前后台界面和业务逻辑）+MySQL数据库（读写分离）
MVC：Spring+Struts+iBatis/Hibernate+Tomcat
共性：垂直应用架构，技术单一，学习成本低，开发上手快，测试，部署，运维比较简单
（2）面临的挑战：
1）复杂应用开发维护成本高，部署效率逐渐降低：代码全量编译，部署一次需要15分钟，只要某个功能编译出错，或者测试出问题，需要重新打包编译
2）团队协作效率差，部分公共功能重复开发，代码重复率高：一些公共能力组件，很难再团队间无缝沟通和共享，导致公共API被重复开发
3）系统可靠性变差：随着访问量攀升，网络流量，负载均衡，数据库连接等都面临巨大压力，某个节点的故障会导致分摊到其他节点的流量陡增，引起“雪崩效应”，高并发，大流量对系统的可靠性要求非常高，垂直架构将所有的应用模块都部署到同一个进程中，如果某个应用接口发生故障，如内存泄漏，会导致整个节点宕机，由于是对等集群部署，这就意味着其他节点也有类似问题，宕机可能此起彼伏，严重影响业务的正常运行
4）维护和定制困难：由于业务代码不断膨胀，功能越来越复杂，已有垂直架构模式下无法对复杂的业务进行拆分，代码修改牵一发儿，维护和定制都非常困难
5）新功能上线周期长：（1）公共API变更导致测试工作量激增（2）新特性无法独立部署和交付
2.远程过程调用（RPC）
（1）远程方法调用，屏蔽底层实现细节，像调用本地方法一样调用远程服务。
这个图对于大多数rpc框架通用，实现的几个技术点： a. 服务提供者发布服务：服务接口定义，数据结构，服务提供者信息等； b.客户端远程调用：通常是使用jdk的代码代理拦截； c. 底层通信：现在应该更多是使用netty吧，当然也有走支持http的； d.序列化：关注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；
（2）业界主流的RPC框架：
1） Facebook开发的远程服务调用框架Apache Thrift
2） Hadoop的子项目Avro-RPC
3） Caucho提供的基于binar-RPC实现的远程通信框架Hessian
4） Google开源的基于HTTP/2和protobuf的通用RPC框架gRPC
3. 面向服务的架构（SOA）
用来解决异构系统的交互，通常的实现是通过ESB，WSDL来处理。其粒度通常来说是比较粗的。也存在服务治理方面的问题。
4.微服务架构（MSA）
（1）MSA也是一种服务化架构风格，正流行ing，服务划分
- 原子服务，粒度细；
- 独立部署，主要是容器；
（2）MSA与SOA的对比：
1） 服务拆分粒度：soa首要解决的是异构系统的服务化，微服务专注服务的拆分，原子服务；
2） 服务依赖：soa主要处理已有系统，重用已有的资产，存在大量服务间依赖，微服务强调服务自治，原子性，避免依赖耦合的产生；
3） 服务规模：soa服务粒度大，大多数将多个服务合并打包，因此服务实例数有限，微服务强调自治，服务独立部署，导致规模膨胀，对服务治理有挑战；
4） 架构差异：微服务通常是去中心化的，soa通常是基于ESB的；
5） 服务治理：微服务的动态治理，实时管控，而soa通常是静态配置治理；
6） 交付：微服务的小团队作战。
有了docker后，微服务这个概念突然火了起来，总结就是微服务+容器+DevOps。