王磊的个人技术记录

1. 架构演变过程

我们最先接触的单体架构，整个系统就只有一个工程，打包往往是打成了 war 包，然后部署

到单一 tomcat 上面，这种就是单体架构，如图：

假如系统按照功能划分了，商品模块，购物车模块，订单模块，物流模块等等模块。那么所

有模块都会在一个工程里面，这就是单体架构。

单体架构优点

1. 结构简单，部署简单
2. 所需的硬件资源少
3. 节省成本

缺点

1. 版本迭代慢，往往改动一个代码会影响全局
2. 不能满足一定并发的访问
3. 代码维护困难，所有代码在一个工程里面，存在被其他人修改的风险

随着业务的拓展，公司的发展，单体架构慢慢的不能满足我们的需求，我们需要对架构进行

变动，我们能够想到的最简单的办法就是加机器，对应用横向扩展。

如图：

这种架构貌似暂时解决了我们的问题，但是用户量慢慢增加后，我们只能通过横向加机器来

解决，还是会存在版本迭代慢，代码维护困难的问题。而且用户请求往往是读多写少的情况，

所以可能真正需要扩容的只是商品模块而已，而现在是整个工程都扩容了，这无形中是一种

资源的浪费，因为其他模块可能根本不需要扩容就可以满足需求。所以我们有必要对整个工

程按照模块进行拆分，拆分后的架构图如下：

模块拆分后，模块和模块之间是需要通过接口调用的方式进行通信，模块和模块之间通过分

流软件进行负载均衡。这个架构解决前面的资源浪费问题和代码管理问题，因为我们是对系

统拆分了，各个模块都有单独的工程，比如我修改商品模块，就不需要担心会不会影响购物

车模块。但是这种架构扩展非常麻烦，一旦需要横向加机器，或者减机器都需要修改 nginx

配置，一旦机器变多了以后，nginx 的配置量就是一个不能完成的工作。OK，这时候 SOA 服

务治理框架就应运而生，架构图如下：

基于注册中心的 SOA 框架，扩展是非常方便的，因为不需要维护分流工具，但我们启动应

用的时候就会把服务通过 http 的方式注册到注册中心。

在 SOA 框架中一般会有三种角色：1、注册中心 2、服务提供方 3、服务消费方

1. 注册中心

在注册中心维护了服务列表

2. 服务提供方

服务提供方启动的时候会把自己注册到注册中心

3. 服务消费方

服务消费方启动的时候，把获取注册中心的服务列表，然后调用的时候从这个服务列表中选

择某一个去调用。微服务工程的特点：

1. 扩展灵活
2. 每个应用都规模不大
3. 服务边界清晰，各司其职
4. 打包应用变多，往往需要借助 CI 持续集成工具
   2.搭建简单的微服务工程
5. 注册中心搭建

Springcloud 中，我们选择 eureka 作为注册中心，springcloud 工程是基于 springboot 工程的。

pom.xml 中 jar 包依赖：

Springcloud 的版本
.
Eureka 服务端启动器导入

Springcloud 的依赖仓库导入

Application.properties 配置文件

启动类

2. 服务提供方

Pom 的 jar 包依赖，其他都跟 eureka 服务端是一样的，只是服务提供方要把服务注册到 eureka

服务端，所以服务提供方就是 eureka 的客户端，所以需要导入 eureka 客户端的启动器。

bootstrap.properties

启动类

3. 服务消费方

pom 和属性配置文件基本上差不多，消费要负责调用服务提供方，所以需要调用客户端

服务调用的时候就根据服务提供方的服务名称来调用的

服务提供方的名称，再加上服务提供方的接口名就可以完成调用了。

服务提供方和服务消费启动的时候都会往服务注册中心注册服务，

eureka 服务端也可以通过

界面查看到服务注册情况：