hello，接下来准备讲解微服务相关的文章，开头先来一篇，了解一下架构的演变过程，从而更好的进一步学习。微服务方面主要讲解Spring cloud周边技术，另外dubbo也会系统的出一系列文章，之前写过一些微服务的但是不够系统。
第一阶段：war包打天下首先看一下下面的架构图：
这个是最先接触的单体架构，整个系统就只有一个工程，打包往往是打成了war包，然后部署到单一tomcat上面，这种就是单体架构。相信大家都很了解，传统项目目前也多数都是这种。
假如系统按照功能划分了，商品模块，购物车模块，订单模块，物流模块等等模块。那么所有模块都会在一个工程里面，这就是单体架构。
单体架构优点
1、结构简单，部署简单
2、所需的硬件资源少
3、节省成本
缺点
1、版本迭代慢，往往改动一个代码会影响全局
2、不能满足一定并发的访问
3、代码维护困难，所有代码在一个工程里面，存在被其他人修改的风险
第二阶段：负载均衡随着业务的拓展，公司的发展，单体架构慢慢的不能满足我们的需求，我们需要对架构进行变动，我们能够想到的最简单的办法就是加机器，对应用横向扩展。如图：
这种架构貌似暂时解决了我们的问题，但是用户量慢慢增加后，我们只能通过横向加机器来解决，还是会存在版本迭代慢，代码维护困难的问题。而且用户请求往往是读多写少的情况，所以可能真正需要扩容的只是商品模块而已，而现在是整个工程都扩容了，这无形中是一种资源的浪费，因为其他模块可能根本不需要扩容就可以满足需求。
第三阶段：模块拆分为了解决第二阶段资源浪费的、代码维护困难等问题，接下来结构再次进行优化改进。如图：
模块拆分后，模块和模块之间是需要通过接口调用的方式进行通信，模块和模块之间通过分流软件进行负载均衡。这个架构解决前面的资源浪费问题和代码管理问题，因为我们是对系统拆分了，各个模块都有单独的工程，比如我修改商品模块，就不需要担心会不会影响购物车模块。但是这种架构扩展非常麻烦，一旦需要横向加机器，或者减机器都需要修改nginx配置，一旦机器变多了以后，nginx的配置量就是一个不能完成的工作。
第四阶段：面向服务为了解决三阶段问题，应运而生的就是SOA服务了。如图：
基于注册中心的SOA框架，扩展是非常方便的，因为不需要维护分流工具，但我们启动应用的时候就会把服务通过http的方式注册到注册中心。
在SOA框架中一般会有三种角色：1、注册中心 2、服务提供方 3、服务消费方
1、注册中心
在注册中心维护了服务列表
2、服务提供方
服务提供方启动的时候会把自己注册到注册中心
3、服务消费方
服务消费方启动的时候，把获取注册中心的服务列表，然后调用的时候从这个服务列表中选择某一个去调用。
微服务工程的特点：
1、扩展灵活
2、每个应用都规模不大
3、服务边界清晰，各司其职
4、打包应用变多，往往需要借助CI持续集成工具
整体上架构演变分为了上述四种，当然细分阶段还有更多，集群分布式，SOA到微服务，数据库方面的读写分离、分库分表等等。有兴趣的同学可以再深入研究。
