架构的演变过程

我们最先接触的单体架构，整个系统就只有一个工程支撑，打包往往是打成了war包，然后部署到单一Tomcat里面，这种架构就是单体架构，如下图：

假如系统按照功能模块划分了，商品模块、购物车模块、订单模块、物流模块等。那么所有模块都会在这一个功能里面，这就是单体架构。

单体架构的优点：

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

缺点：

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

随着业务的扩展，公司的发展，单体架构慢慢的不能满足公司业务发展的需求，我们需要对架构进行变动，我们能够想到的最简单的办法就是增加机器，对应用横向扩展。如下图：

这种架构暂时解决了我们的问题，但是用户量慢慢增加后，我们只能通过横向加机器来解决，还是会存在版本迭代慢，代码维护困难的问题。而且用户请求往往是多读写少的情况，所以可能真正需要扩展的只是商品模块而已，而现在是整个工程都扩容了，这无形中是一种资源的浪费，因为其他模块可能根部不需要扩容就可以满足用户需求。所以我们有必要对整个工程安装模块进行拆分，拆分后的架构图如下：

模块拆分后，模块和模块之间是需要通过接口调用的方式进行通信，模块和模块之间通过分流软件进行负载均衡。这个结构解决的前面的资源浪费问题和代码管理问题，因为我们是对系统拆分了，各个模块都有单独的工程，比如我修改商品模块，就不需要担心会不会影响购物车模块。但是这种架构扩展非常麻烦，一旦需要横向加机器，或者减机器都需要修改nginx配置文件，一旦机器变多了以后，nginx的配置就是一个不能完成的工作。OK，这个时候SOA服务治理框架就因用而生，架构图如下：

基于注册中心的SOA框架，扩展是非常方便的，因为不需要维护分流工具，但我们启动应用的时候就会把服务通过http的方式注册到注册中心。
在SOA框架中一般会有三种角色：1、注册中心 2、服务提供方 3、服务消费方。

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

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

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

微服务工程的特点：
1、扩展灵活
2、每个应用都规模不大
3、服务边界清晰，各司其职
4、打包应用变多，往往需要借助 CI 持续集成工具