springcloud 系列教程一：微服务与网站架构演变过程

什么是微服务？

微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之

究竟什么是微服务呢？我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

看不懂？？？我有什么办法，反正我能看得懂

我们先来看看传统的项目模式

这是一个办公系统示例，里面有好几个模块，那么假设有个 low 逼程序员写了个性能非常差的代码在财务管理这个模块里面，导致数据库崩溃，那么整个项目都会受到影响，这是非常糟糕的情况

所以我们来总结下传统模式的缺点：

1. 项目过于臃肿当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护

2. 资源无法隔离，整个系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮，耦合度太高

3. 当系统的访问量越来越大的时候无法灵活扩展，虽然可以进行水平扩展，部署在多台机器上组成集群，但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的

现在对上面的结构图进行优化

我们将每个功能模块提取出来单独去开发部署，客户端、每个模块之间都可以互相调用实现解耦，当然这只是一个简单的示例而已

微服务的特点：

1. 独立部署，灵活扩展传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如员工管理服务，财务管理服务）为单位进行部署 用一张经典的图来表现，就是下面这个样子（左边是传统项目集群，右边是微服务集群）：

1. 资源的有效隔离微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题
2. 团队组织架构的调整微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA 有 DBA 的团队，测试有测试的团队。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责（当然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对）

网站架构演变过程

单体架构

单体架构也称为传统架构，说白了就是我们经常写的 SSM 或者 SSH 应用，特点就是将整个业务都在一个项目中开发，整个项目一般都分控制层、业务逻辑层、数据访问层，这种项目一般只适合小项目开发

缺点：耦合的太高，一旦某个模块崩溃，可能会影响到整个项目的运行

分布式架构

分布式架构是基于传统架构演变过来的，即将传统的项目以模块拆分成多个子项目，比如：会员项目、订单项目、商品项目等。每个项目都有自己独立的数据库，注意这里是子项目，代表每个子项目都有完整的 mvc 结构

比较：分布式架构比传统架构粒度更细，耦合度降低，更适合团队开发

maven 管理的多模块项目是分布式架构吗？？

不一定，如果你仅仅是将项目拆分成 entity、service、dao 几个子工程，然后通过 maven 依赖引入，那其实最终打包后还是一个 war 包啊，其实依然是一个项目。但是如果你打包成多个项目部署，互相通信，那可以称为分布式项目

SOA架构

SOA:（Service Oriented Architecture） 面向服务的架构。把工程拆分成服务层、表现层两个工程，服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需处理和页面的交互，业务逻辑都是调用服务层的服务来实现

SOA 是一个组件模型，它将应用程序的不同功能单元（成为服务），通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，他应该独立于实现服务的硬件平台、操作系统、和变成语言。这是的构建在各种各样的系统中的服务可以从一种统一和通用的方式进行交互

SOA 是把服务分成了若干，表现层分成了若干。表现层和服务层没有耦合关系，表现层可以用任意一个服务层，开发的时候，仅仅是增加服务层和 web 层2个工程，并不会把服务层和 web 层当成一个整个工程。他们是独立的。而分布式架构是 web 和服务层紧紧联系到了一起，一个 web 层对应一个服务层。所以 SOA 比分布式架构更加解耦合，扩展也更容易

标准架构图：

核心组件：ESB 企业服务总线

ESB 全称为 Enterprise Service Bus，即企业服务总线。它是传统中间件技术与 XML、Web 服务等技术结合的产物。ESB 提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB 的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合

特点：

1. 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务
2. 各各项目（系统）与服务之间采用 webservice、rpc 等方式进行通信
3. ESB 企业服务总线作为项目与服务之间通信的桥梁

优点：

1. 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性
2. 可以针对不同服务的特点制定集群及优化方案
3. 采用 ESB 减少系统中的接口耦合

缺点：

1. 系统与服务的界限模糊，不利于开发及维护
2. 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护
3. 抽取的服务的粒度过大，系统与服务之间耦合性高