『互联网架构』软件架构-从0到1认知分布式架构（下）（39）

上次说了分布式架构的历史，分布式架构需要考虑的问题，这次继续说分布式架构。

轻量级架构 会采用 Http+Nginx

负载均衡+容错+服务配置+健康检测 这些功能怎么解决呢？一个一个的去编码实现么？。有没有现成的方案可以直接实现这些功能？Nginx完全支持这些功能。所以企业在做轻量级架构 会采用 Http+Nginx 方式。 这个架构有什么瓶颈，nginx挂了的话，是不是服务都不行了，可以在中间层可以搞keeplived，做nginx的负载。

完成nginx内部的负载，Nginx本身还可以根据业务进行垂直拆分。如果用户server1，直接到serverN了怎么办，其实这个架构本身就是轻量级的，本身就支持不了了。

有老铁爱说，性能不够加服务器，在于自身是否支持弹性的扩展，如果系统不支持，加服务器没用的。

• 优点

简单快速、几乎没有学习成本

• 适用场景

轻量级分布式系统、局部分布式架构。

• 瓶颈

Nginx中心负载、Http传输、JSON序列化、开发效率、运维效率。

1.Http传输

http传输本身比较复杂有请求头，有请求体，传输内容比较多。如果RPC就不用考虑这些。

2.JSON序列化

真心不高，比java的二进制序列化效率还要低，最大的瓶颈就在于json的解析上。

3.运维效率

server1，server2的配置都是在nginx上的，配置多的话对于运维人员增加了工作量。

4.开发效率

也不是不高，反正就是需要解析麻烦，还得拼麻烦。

5.Nginx中心负载

层和层之间通信，消耗nginx，nginx中心进行负载，肯定没有直接连接块，毕竟有中间商【赚差价】

• 基于瓶颈考虑大型系统需要一个更加专业的方案，该方案必须做到以下几点：

springcloud和dubbo就是按照这些设计方案来进行设计的。

1.去中心化，客户端直连服务端 2.动态注册和发现服务 3.软负载均衡实现 4.高效稳定的网络传输 5.高效可容错的序列化

• （1）注册中心逻辑 1.服务端动态注册服务提供者信息 2.客户端从注册中心接收服务提供者信息，并存储至本地缓存 3.注册中心实时监听提供者状态，如果变更将即时通知客户端
• （2）调用逻辑 1.负载均衡 2.容错 3.对服务调用者透明，操作数据库的时候只需要操作对应的接口，就可以完成对数据库的操作，这个就是透明。
• （3）传输模块 mina、servlet 容器、netty
• （4）序列化模块 kryo、hessian、java、protobuf、JSON、XML
• 所有RPC框架的逻辑

主流的框架比较

• spring cloud

本身是个技术栈， 服务发现——Netflix Eureka 客服端负载均衡——Netflix Ribbon 断路器——Netflix Hystrix 服务网关——Netflix Zuul 分布式配置——Spring Cloud Config

• Doubbo

Provider：暴露服务的服务提供方 Container：服务运行容器 Consumer：调用服务的消费方 Registry：注册服务与发现服务中心 Monitor：统计服务调用的监控中心（可有可无） 官网：http://dubbo.apache.org/zh-cn/docs/user/quick-start.html

PS：微服务的业内主流的java框架就是springcloud 和dubbo，他们的设计思路都是按照分布式的设计思路来的，主要还是围绕服务，发现，注册，调用，负载。一定要明白他的设计思路。这样对学习springcloud和dubbo好处多多。