第一章：

　　理论基础：

　　互联网企业对传统技术进行发展和演化，形成一套具有互联网特色的互联网技术，互联网技术以拆分为原则来满足服务于海量 用户的需求，从架构上来讲，分布式、服务化( 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。

　　到现在为止， SSH 开源标配框架中有了四交互层的 Stru也框架和业务逻辑实现层的 Spring 框架，由于面向对象领域的模型与关系型数据库存在着天然的屏障，所以对象模型和关系模型之 间需要一个纽带框架，也就是我们常说的 ORM 框架，它能够将对象转化成关系，也可以将关系 转化成对象，于是， Hibernate框架出现了。 Hibernate通过配置对象与关系表之间的映射关系，来 指导框架对对象进行持久化和查询，并且可以让应用层开发者像执行 SQL 一样执行对象查找 。 这 大大减少了应用层开发人员写 SQL 的时间 。然而，随着时间的发展，高度抽象的 ORM 框架被证 明性能有瓶颈，因此，后来大家更倾向于使用更加灵活的 MyBatis 来实现 ORM 层 。 

缺点：

　　SSM框架还是没有摆脱传统的单JVM的劣势，远远满足不了高并发的场景。

　　服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件精合在一个开发项目中，并且配置和运行在一个JVM中 。 如果某个模块化组件需要升 级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的 变更，由于种种原因，会导致其他模块化组件出现问题。 

　　在互联网异军突起的环境下，传统 JEE和 SSH无法满足对海量用户发起的高井发请 求进行处理的需求，无法突破稿合在 一起的模块化组件的性能瓶颈，单一进程己经无法满 足需 求，并且水平扩展的能力也是很有限的。 

面向服务架构：