第一章：
理论基础：
拆分为原则来满足服务于海量 用户的需求，从架构上来讲，分布式、服务化( SOA )、 微服务得到了深入发展，以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分解，采用分而治之的方法，达成用户需要的功能指标，并同时满足用户对高可用性、高性能、 可伸缩、可扩展和安全性的非功能质量的要求。
这断话摘自书中的一段内容，从这段话中我们可以思考，分布式理论中使用了两个主流的技术，以SOA服务化为基础，采用分而治之的思想进行业务处理；
何为分而治之：将一个大任务划分为几个子任务，并行执行后，将结果合并的思想；
在大数据处理中同样采用分而治之的原理进行处理，比如下面的案例：在对5万张扑克牌进行处理筛选漏掉的一张时，就可以将5万张牌进行拆分为5个，然后这5个并行计算各个牌的个数，计算完成后进行各个花色的统计，最后进行结果的筛选；
从传统单体架构到服务化架构 ：
原始的EJB架构：
缺点：
尽管大多数公司会 使用规范来约束不同业务逻辑的隔离性来解祸，但是久而久之，随着复杂业务逻辑的选代增加 及开发人员的不断流动，新手工程师为了节省时间
和赶进度，非法使用了其他组件的服务，业务组件之间、 组件之间、数据存取之间的稿合性必然增加，最后导致组件与组件之间难以划 清界限，完全祸合在一起，
将来的新功能迭代、增加和维护将难上加难。
SSH框架：
SSM框架的优点：
对Spring进行优点简述：
开源框架 Spring 的发布，更加改变了 JEE 一开始制定的战略目标。 Spring框架作为 逻辑层实现的核心容器，使用起来简单、方便又灵活，几乎大部分开发者完全倒向了 Spring开源派。 Spring 框架有两个核心思想: IOC 和 AOP，如下所述 。
Spring IOC 指的是控制翻转，将传统 EJB 基于容器的开发改造成普通的 Java 组件的开发， 且在运行时由 Spring容器统一管理和串联，服务于不同的流程，在开发过程中对 Spring容器没有强依赖，便于开发、测试、验证和迁移。使用 EJB 实现一个服务化组件 Bean 时，需要依赖于多个容器接口 ，并需要根据容器的规则进行复杂的 XML 配置，测试需要依赖于应用服务器的环境，有诸多不便;使用 Spring框架则不然，开发业务逻辑时每个业务逻辑的服务组件都是独立的， 而不依赖于 Spring框架，借助 Spring容器对单元测试的支持，通过对下层依赖服务进行 Mock, 每个业务组件都可以在一定范围内进行单元化测试，而不需要启动重型的容器来测试。
Spring 对 AOP 的支持是 Spring 框架成功的另外一大核心要素。 AOP 代表面向切面的编程， 通常适用于使用面向对象方法无法抽象的业务逻辑，例如:日志、安全、事务、应用程序性能管 理(APM) 等，使用它们的场景并不能用面向对象的方法来表达和实现，而需要使用切面来表达， 因为它们可能穿插在程序的任何一个角落里。在 Java 的世界里， AOP 的实现方式有如下 三种 。
· cglib库实现，对 Java字节码进行重新编译，将切面插入宇节码的某些点和面上 。
· 定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻 辑外的功能， NM 自身提供的 Java Agent 机制就是在加载类的宇节码时，通过增加切 面来实现 AOP 的。
•NM 本身提供了动态代理组件，可以通过它实现任意对象的代理模式，在代理的过程中可 以插入切面的逻辑。可以使用 Java提供的 APIProxy.newProxylnstanceO和 InvocationHandler 来实现。
AspectJ是实现 AOP 的专业框架和平台，通过 AspectJ可以实现任意方式的字节码切 面， Spring框架完全支持 AspectJ。
后来大家更倾向于使用更加灵活的 MyBatis 来实现 ORM 层 。
缺点：
SSM框架还是没有摆脱传统的单JVM的劣势，远远满足不了高并发的场景。
服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件精合在一个开发项目中，并且配置和运行在一个JVM中 。 如果某个模块化组件需要升 级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的 变更，由于种种原因，会导致其他模块化组件出现问题。
在互联网异军突起的环境下，传统 JEE和 SSH无法满足对海量用户发起的高井发请 求进行处理的需求，无法突破稿合在 一起的模块化组件的性能瓶颈，单一进程己经无法满 足需 求，并且水平扩展的能力也是很有限的。
面向服务架构：
