开发架构的变迁
1传统型的开发采用的都是基于mvc 架构的开发，这种模式 把页面 控制 模型分开了，
使得代码更具有可读性和可扩展性，随着业务越来越多，
不同的模块之间可能会调用相同的服务（同一个处理逻辑），
这个时候就把 这同一个处理逻辑（服务） 独立出来，单独部署了，然后rpc 出现了。
其他系统通过rpc (远程过程调用的方式来调用这个服务)。
2 远程过程调用起来也很方便，服务的负载均衡采用F5硬件负载均衡器 或者slb 进行简单的负载均衡。
但是随着独立出来的服务越来越多，慢慢的服务的管理成了问题，
1）服务url 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。
这时候就需要一个注册中心，动态的注册和发现服务，是服务的位置透明化，消费者本地缓存服务提供者列表，
实现软负载均衡。
2）服务间的依赖关系变得错综复杂，甚至分不清楚哪个应用要在哪个应用之前启动。需要一个分布式消息跟踪系统可视化展示服务调用链。
来做依赖分析，业务调用路径梳理等。
3) 容量问题：某个服务需要多少机器支撑，什么时候该加机器，需要采集服务调用kpi 数据，进行亏总和分析，然后计算出合理的服务部署实例个数。
随着问题越来越多，服务治理 已经变得不可或缺，这样soa 诞生了。
3 soa 是一种思想，基于服务开发的架构，rpc 的出现是因为有服务独立出来了。soa 的思想是把所有可能服务化的东西，全都服务化，
但是这个服务化 是粗粒度的，一般一个服务就是一个业务逻辑的处理（里面可能包含了一个流程）。
soa 更强调的是服务治理，rpc 框架+服务治理 就是 soa 。
服务治理包括什么？服务发现，服务监控，服务限流，服务降级，服务签入签出，服务动态路由，服务灰度发布，消息跟踪，服务优先级，服务异常定位等。
但是 慢慢发现，服务本身不够原子化，换句话说，如果想修改一个简单基础服务，可能其他服务也要跟着做改动。
敏捷开发要求设计，开发，上线迅速，所以服务细化也是有必要的，方便敏捷开发。
4 所以微服务诞生了，微服务侧重的就是 服务原子化，服务之间没有依赖，服务设计，开发，上线快捷迅速。
微服务有两个核心：
- 微：服务的粒度要细，即服务要细化到API
- 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)
上面两个核心总结起来，可以用下面这幅图表示：
从上面这幅图看出，微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。
我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。
说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。
微服务的实现
微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。
微服务的特点
服务需要再细化成API（服务接口——>服务API）
- 每个服务由一组API组成
- 以API形式对外提供统一格式的服务
- 使用者无需任何配置，直接调用（http）
- 完整的API文档
- API服务安全可靠稳定
微服务要解决的问题
上面提到了，dubbo还存在一些问题 ，其实dubbo存在的问题 就是 微服务要解决的问题，这里 再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。
- 统一入口
- 安全控制：防刷限流
- 统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
- 协议转换：http、dubbo、Protobuf
- API配置管理
- API上线、下线
- API与服务接口映射
- 监控与报警
- 整体架构的可拓展、高并发、分布式
- 服务容器自动收缩、扩容
实现方案
- 负载均衡层：nginx/lvs/F5
- 微服务层
- 高性能服务网关
- 统一入口、API配置管理、分流鉴权、服务监控、协议转换
- API映射、OAuth2.0、API文档管理
- 分布式、可拓展
- 服务治理层
- 成熟的服务治理框架dubbo
- MQ服务之间解耦
- 弹性云
- 服务docker化
- 基于访问压力的实时集群调度与管理
弹性云
这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。
