服务架构演进
服务架构演进过程：抽取各个模块独立维护，独立部署的过程。
初创公司2 ~ 3个研发人员，ALL IN ONE 的框架开发效率最高。随着队伍的壮大，产品，用户，商品成立独立小组，拆出相应的模块，独立维护，相互不影响，根据不同流量，分配不同的服务器。然而也带来了问题：业务之间的相互调用问题。于是不同部门将一些公共服务，抽取出来，做成rpc 服务，供其他兄弟部门调用。
ALL IN ONE
关键点：数据访问层（ORM）是关键。
优点：
- 简单。
- 减少部署节点和成本。
缺点：
- 扩展不容易。
- 不易系统开发。
- 商品的bug，可能影响到用户服务的稳定性
垂直应用架构
关键点：前端页面开发的 Web 框架（MVC）是关键。
每个独立应用：页面，http 服务，数据库。
独立扩展：用户量和商品访问量大了，增加对应的服务器就可以了。
独立开发，互补干扰。
性能扩展方便。
缺点：
- 无法做到页面和业务逻辑的实现分离。页面改动频繁，业务逻辑修改较少。
- 业务逻辑无法完全独立，大量应用需要交互。订单系统：需要用户和商品的服务。支付也需要用户的信息等等。
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服
务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,
用于提高业务复用及整合的分布式服务框架(RPC)是关键。
抽取出：Web 页面 和 rpc 服务。
因为web 和 业务服务不在同一台服务器。需要远程调用，所以上rpc（远程过程调用）。
注册中心
通过注册中心：治理服务。
服务发现，服务动态扩容。
流动计算架构
https://martinfowler.com/articles/microservices.html
微服务
优点：
- 每个服务足够内聚，足够小
微服务技术栈：
| 微服务条目 | 落地技术 | 备注 |
|---|---|---|
| 服务开发 | SpringBoot，Spring，SpringMVC | |
| 服务配置与管理 | Neffix 的 Archaius，阿里的Diamond | |
| 服务注册与发现 | Eureka，Consul，ZooKeeper，Nacos | |
| 服务调用 | Ribbon，Rest，RPC，GRPC | |
| 服务熔断 | Hystrix，Envoy，sentienl | |
| 负载均衡 | Ribbon，Nginx 等 | |
| 服务接口调用（客户端调用服务的简化工具） | Feign等 | |
| 消息队列 | Zuul等 | |
| 服务配置中心管理 | Zabbix，Negios，Metrics，Spectator，Nacos | |
| 服务路由（API 网管） | Zuul等 | |
| 服务监控 | Zabbix，Negios，Metrics，Spectator等 | |
| 全链路追踪 | Zipkin,Brave,Dapper等 | |
| 数据流操作开发包 | Spring Cloud Stream（封装与Redis，Kafka等发送接受消息） | |
| 事件消息总线 | Spring Cloud Bus，Nacos | |
| 服务部署 | Docker，OpenStack，Kubernetes等 |
主流 IT 公司：
阿里：Dubbo/HSF
京东JSF
新浪微博Motan
当当网 DubboX
| Netflix/Spring cloud | Netflix/Spring cloud | Motan | GRPC | Thrift | Dubbo/DubboX |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服务框架 | RPC 框架，但组合了ZK或Consul，实现集群环境的基本的服务注册/发现 | RPC 框架 | RPC 框架 | 服务框架 |
| 支持Rest | 是，Ribbon 支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
| 服务注册/发现 | |||||
| 负载均衡 | 是（服务端zuul+客户端Ribbon） | 是（客户端） | 否 | 否 | 是（客户端） |
| 服务配置 | |||||
| 支持多语言 | 是(Rest 形式) | 否 | 是 | 是 | 是（客户端） |
创建微服务模块步骤：
- 建 module
- 该 POM
- 写 YML
- 启动类
- 业务类
业务类：
- 写 SQL
- entities
- dao
- service
- controller