分布式微服务架构设计原理——迷茫看看篇

互联网企业从事信息技术的研发、生产和运营，与传统企业相比，互联网企业倾向于对特 定的人群提供专用服务，这导致互联网产品多种多样、数量众多。由于传统的软件技术更倾向 服务于企业，用户较少，所以传统的企业级技术无法满足互联网产品服务于海量用户的需求． 于是，互联网企业对传统技术进行发展和演化，形成一套具有互联网特色的互联网技术．互联 网技术以 拆分为原则来满足服务于海量用户的需求， 从架构上来讲，分布式、服务化（ SOA ）、 微服务得到了深入发展，以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分 解，采用分而治之的方法，达成用户需要的功 能指标，并同时满足用户对高可用性、高性能、 可伸缩、可扩展和安全性的非功能质量的要求。

我在做电商的时候遇到了很多颈瓶和缺乏一些概念性的知识，我感觉必须要有一些基础性的知识来支撑着我电商项目的开发，所以做了如下笔记，方便以后阅读

1：从传统单体架构到服务化架构

1.1 JEE架构

JEE 以面向对象的 Java 编程语言为基础，扩展了 Java 平台的标准版，是 Java 平台企业版 的简称。它作为企业级软件开发的运行时和开发平台，极大地促进了企业开发和定制信息化系 统的进展。
JEE 将企业级软件架构分为三个层级： Web 层、业务逻辑层和数据存取层，每个层次的职 责分别如下。

Web 层： 负责与用户交互或者对外提供接口 。
业务逻辑层：为了实现业务逻辑而设计的流程处理和计算处理模块。
数据存取层： 将业务逻辑层处理的结果持久化以待后续查询，并维护领域模型中对象的 生命周期。

JEE 平台将不同的模块化组件聚合后运行在通用的应用服务器上，例如 ： WebLogic、 WebSphere, JBoss 等，这也包含 Tomcat， 但 Tomcat 仅仅是实现了 JEE Web 规范的 Web 容器。 JEE 平台是典型的二八原则的一个应用场景，它将 80%通用的与业务无关的逻辑和流程封装 在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现 20%的 专用逻辑，并通过配置的形式来访问应用服务器提供的模块化组件。事实上，应用服务器提 供的对象关系映射服务、数据持久服务、事务服务、安全服务、消息服务等通过简单的配置 即可在应用程序中使用 。

JEE时代架构如下

JEE 时代的架构已经对企业级应用的整体架构进行了逻辑分层，包括上面提到的 Web 层、业 务逻辑层和数据存取层，分别对应图 中的 Web 容器、 EJB 容器和数据存取 ORM 组件与数据 持久层 （数据库）， 不同的层级有自己的职责，并从功能类型上划分层级，每个层级的职责单一。

JEE架构带来的问题

每个层次的 多个业务逻辑的实现会被放在同一应用项目中，并且运行在同一个JVM 中。尽管大多数公司会 使用规范来约束不同业务逻辑的隔离性来解祸，但是久而久之，随着复杂业务逻辑的选代增加 及开发人员的不断流动，新手工程师为了节省时间和赶进度，非法使用了其他组件的服务，业 务组件之间、 UI组件之间、数据存取之间的稿合性必然增加，最后导致组件与组件之间难以划 清界限，完全祸合在一起，将来的新功能迭代、增加和维护将难上加难。
另外，由于血E 主要应用于企业级应用开发，面向的用户较少，所以尽管 JEE 支持 Web 容器和 EJB 容器的分离部署，这个时代的大多数项目仍然部署在同一个应用服务器上并跑在一 个JVM进程中。

1.2 SSH 架构

Sun 公司是 JEE 规范制定的始作俑者，早在传统企业全面信息化的初始阶段， Sun 公司看 到了企业信息化建设的巨大市场，在制定 JEE 规范时，更注重规范的全面性和权威性，对企业 级应用开发的方方面面制定了标准，并且联合 IBM 等大型企业进行推广。 然而，在铺天盖地的 规范和标准的限制下开发出来的符合 JEE 规范的应用服务器，不但没有简化在瘦客户环境下的 应用开发，反而加重了开发者使用的成本和负担，尤其是早期 EJB 版本（2.0）的实现由于大量 使用了 XML 配置文件，所以实现一个服务后的配置工作颇多， EJB 组件学习曲线较高，又难 以做单元测试，被称为超重量级的组件开发系统。
在 JEE 开始流行但没有完全奠定其地位时，开源软件 Struts、 Spring 和 Hibernate 开始崭露 头角， 很快成为行业内企业开发的开源框架标配（简称 SSH), JEE 规范中的各种技术如 EJB, 迅速失去了进一步发展的机会。 Web MVC 框架 Struts 在用户交互的 UI 层进一步划分了前端的 职责，将用户交互层划分为视图、模型和控制器三大块（简称 MVC 模型），其结构示意图如 下

在那个时代， Struts MVC 模型几乎服务于大多数企业服务的 Web 项目。
后来，开源框架 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 的实现方式有如下三种。

1. 对 Java 字节码进行重新编译，将切面插入宇节码的某些点和面上，可以使用 cglib 库实 现。
2. 定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻 辑外的功能， NM 自身提供的 Java Agent 机制就是在加载类的宇节码时，通过增加切 面来实现 AOP 的。
3. NM 本身提供了动态代理组件，可以通过它实现任意对象的代理模式，在代理的过程中可 以插入切面的逻辑。可以使用 Java 提供的 APIProxy.newProxylnstanceO和 InvocationHandler 来实现。

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

这一时代的 SSH 架构与 JEE 时代的架构类似，可分为三个层次：实现交互 UI 接口的 Web MVC 层、实现业务逻辑的 Spring 层及实现对象关系映射的 Hibernate 层，每个层级的实现比 JEE 对应的层次更简单、更轻量级，不需要开启整个应用服务器即可测试和验证，极大提高了开发 效率，这得益于 Spring 框架的控制翻转理念。
由于这一时代的企业级软件服务的对象仍然是企业，用户量并不大，因此，大多数企业里 的 SSH 架构最终会被打包到同一个 JEE 规范的 War 包里，并且部署在 Apache Tomcat Web 容器 里，因此，整个结构还是趋向于传统的单体架构，业务逻辑仍然糯合在一个项目中，即使通过 规范来约束模块化组件的精合度，效果也往往适得其反。
这一时代的职能团队的划分仍然停留在层次上，与 JEE 架构下的职能团队划分类似，分为 前端团队、后端业务逻辑研发团队和 DBA 团队。

1.3 服务化架构

1：从JEE时代到SSH时代，服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有 组件精合在一个开发项目中，并且配置和运行在一个口叫进程中。如果某个模块化组件需要升 级上线，则会导致其他没有变更的模块化组件同样上线，在严重情况下，对某个模块化组件的 变更，由于种种原因，会导致其他模块化组件出现问题。
2：另外，在互联网异军突起的环境下，传统JEE和SSH无法满足对海量用户发起的高井发请 求进行处理的需求，无法突破稿合在一起的模块化组件的性能瓶颈，单一进程己经无法满足需 求，并且水平扩展的能力也是很有限的。
3：为了解决上述问题，S