第一篇主要以下内容：
第一： 传统架构演进
第二： 微服务核心基础
第三：常见的微服务框架
第四：SpringCloud的版本
第一： 传统架构演进
在早期阶段，许多公司的业务并不庞大，用户量少，公司系统的架构多数为单机应用，但随着业务的发展，功能的增加，用户量逐渐增大，现有的单机应用以及不能满足业务的发展，也无法支持庞大的用户群体访问，很多公司开始将原有的单机系统通过按业务拆分成多个微服务进行开发部署。
-
传统架构(单体应用)：
-
传统架构(单体应用采用分布式部署)：
单体应用但将系统部署多台服务器上，通过Nginx负载均衡到每一台服务器减轻服务器访问压力，数据库搭配主从库即使主数据库挂掉了，从数据库也能顶上去。
-
微服务架构：
将单体应用系统按业务拆分成多个模块，比如用户的注册、登入等抽离出来开发成一个项目，把这个项目部署到服务器上去，再部署多个节点变成集群的模式，每个服务提供接口进行访问。
单体应用：
开发速度慢、启动时间长、依赖庞大等不足。
微服务应用：
优点：容易开发、理解和维护，独立部署和启动等。
不足：分布式系统事务问题、需要管理多个服务治理等。
第二： 微服务核心基础
- 网关：主要用于路由转发 + 过滤器
举例：
接口 /app/v1/order 和接口 /app/v1/user 网关可以根据接口进行判断将 /app/v1/order 转发给订单服务 /app/v1/user 转发给用户服务进行处理。
然后通过过滤来判断该用户是否登入，登入了才能有下单的操作。 - 注册中心：调用方和被调用方的信息维护。
举例：
项目启动商品服务会把它的 IP和端口 记录到注册中心里面，等到下单时订单服务会跟注册中心要商品服务的IP接口，注册中心就会把商品服务的接口返回给订单服务进行调用。 - 配置中心：管理配置多态更新。
举例：
将多个服务的配置 application.yml 进行统一的管理，如果订单服务的 IP 或者端口更改了，只能去每个应用下一个一个寻找配置文件然后修改配置文件再重启应用。但使用了配置中心直接在配置中心修改，然后订单服务直接拉取下来即可。 - 链路追踪：分析调用链路耗时。
举例：
下单时，订单系统需要调用商品服务查询商品价格，商品详情等，也需要调用用户信息，但如果经历多个服务的调用链路一旦变长，那么响应时间就会变慢，通过链路追踪可以查看到调用哪个服务导致系统变慢。 - 负载均衡：分发负载。
- 熔断：保护自己和被调用方。
举例：在双十一这种流量特别大的时候，下单时如果调用积分服务没有迟迟没有响应那么就会进行熔断处理，停止调用它，等过一个时间点在进行调用，如果接口访问量过大也会进行一个降级处理。
第三：常见的微服务框架
consumer：调用方
provider：被调方
-
dubbo：zookeeper + dubbo + springmvc + springboot
通信方式：rpc
注册中心：zookeeper / redis
配置中心：diamond -
SpringCloud：全家桶 + Netflix 第三方组件
通信方式：http restful
注册中心：eruka / consul
配置中心：config
断路器：hystrix
网关：zuul
链路追踪：sleuth + zipkin -
功能对比
第四：SpringCloud的版本
Spring Cloud 的版本号并不是我们通常见的数字版本号，而是一些很奇怪的单词。这些单词均为英国伦敦地铁站的站名。同时根据字母表的顺序来对应版本时间顺序，比如：最早 的 Release 版本 Angel，第二个 Release 版本 Brixton（英国地名），然后是 Camden、 Dalston、Edgware、Finchley、Greenwich、Hoxton。
