这是我参与更文挑战的第11天，活动详情查看： 更文挑战

微服务的发展历程

单体架构

所谓单体架构，顾名思义，就是一个项目打出来的jar包或者war包涵盖了应用的所有的功能

使用范围

在业务的发展初期，系统功能相对初级，追求的是简单、高效，快速迭代和上线。这个时候往往采用单体式架构。

集群及垂直化

何为集群

在这个阶段，一开始所有的功能任然在同一个工程内打出一个jar包或者war包，但是会把这个工程同时多处运行，然后通过引入反向代理做负载均衡，当然此时它们还是共用一个数据源，这种运行方式成为集群

何为垂直化

程序方面可以通过不断增加新的jar包（war包），然后通过负载均衡能够在应用程序出分担访问的压力，但是对于应用功能的变动却不灵活，并且数据库共用一个的话也会有数据库方面的压力，那么则需考虑程序以及数据库的垂直拆分（根据不同业务功能拆分出不同的数据库）和一些大表的水平拆分（某个功能数据过多的话进行分库分表）

实现

把Service1和Service2由原本的一个应用程序拆分为两个应用（打出各自的jar包或者war包），数据库也根据业务来进行拆分为DB1（对于Servic1）和DB2（对于Service2）数据库

SOA

出现契机

有时候业务功能不是彻底的分离，各个服务直接也会由关联的，比如Service1是用户服务，Service2是订单服务，那么订单服务生成订单的时候需要用包含用户信息，而订单服务本身的数据是不保存用户信息的，那么则需要调用用户服务来提供，如果很多服务都要用到用户服务，那么对于用户服务来说压力很大，如何解决呢？

这时就出现了SOA框架了

服务提供者通过将自己注册到服务注册中心(常见的解决方案是Zookeeper、Nacos)，客户端调用时，先根据服务名称(可能还有机房、分组、版本号等)信息，找到服务调用地址(服务提供者注册是提供)，再根据服务调用地址调用。

服务提供者将自己注册为Zookeeper的临时节点，宕机后临时节点会消息，客户端通过Watch监听Zookeeper临时节点的变化，通过感知变化将不可用的节点从调用列表里摘除。

最后，由SOA到微服务是怎样的关系呢？

微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

比如（请看最后一图）

真正的微服务架构

今日小结
今天讲了微服务的发展历程，从刚开始的单体–>集群及垂直化—>SOA(升华到微服务)，Over！