又有个新朋友问我分布式，我表示了一下自己的看法， 也与大家分享一下。
一、要点
- 单应用服务器：客户端的请求全部由一个服务器完成。服务器挂了就请求不了。只适合用户量比较小的小型网站。
- 负载均衡(集群)： 部署多个单应用(每台服务器部署的应用相同)，然后通过nginx或其他软件对客户端的请求进行分发分工。即使其中某一个或者多个坏了，剩下的仍在工作仍可请求通完成任务。相比单应用服务器，能有效的解决高并发和服务器压力。
- 分布式：将整个系统的功能进行拆解，根据业务功能模块分别部署到不同的服务器上，各个业务模块之间通过接口进行数据交互。分布式如果挂了一个服务器则这个服务器上对应的功能就用不了，其他的能用。比如充值提现服务器挂了则仅充值提现业务受到影响，其他如注册下单等等均可正常使用。
- 微服务：与分布式差不多，但是拆分的更细。
二、效率比较
假如10个请求，每个请求处理需10s。
- 单应用：每次处理花费10s，依次请求10次，共需100s完成。
- 负载均衡：假设10台服务器集群而成。那么10个请求每台分配一个，同时工作，共需10s完成。
- 分布式、微服务：假设一个请求需要10道没有依赖关系(指必须先做完这一步才能做下一步)的工序，一个请求需要本来需要10s，现在把这个请求分解成10道工序分别给10台服务器同时处理，最终这个请求总需时就是1s完成。10个请求就是10s。所以分布式的原理就是通过缩短每个请求的完成时间来提交效率的，负载均衡是靠人多产量大。
- 分布式+集群：分布式是拆成了多个子系统，某子系统也只是在某一台服务器。我们可以把这个子系统所在服务器当做一个单点服务器，当请求并发量很大时，这道工序到他这也是要排队可能忙不过来就是个瓶颈了。如果对其做10个服务器的集群，在请求量很大的情况下那这道工序完成的时间也会缩短很多，而且可以避免他这单一服务器挂了导致影响整个系统业务流程。
三、注意点：
1 负载均衡
1.1 需做好共享,如 session ，公共文件夹 等等
1.2 更新代码每台服务器都要更新一下。最好是先全部关闭，每台更新完毕后在逐个重启。尽量不要更新完一台就重启然后接着下一台，因为更新完了的是最新代码，还没更新的是老代码，如果在这个过程中分发交差了新老代码的服务器难免出问题。
1.3 如有定时任务只需要一台服务器执行就好，不要每台都执行一遍。(可以给定时任务做个开关标志写配置文件里面仅一台服务器配上标志)
2 分布式&微服务
2.1 需注意事务管理，不要最后交易失败了出现有些事务提交了有些回滚了。
2.2 修改了不在服务注册监控中心的东西，需要重启中间件才能生效。
2.3 若集群，根据业务决定集群数量，一般1-4台即可，多了也要成本。重点业务、请求并发大的子系统集群数量可以多几台，反之可以少几台或单台
2.4 缺点：需要的硬件、人力成本多，排查问题牵扯的太多服务和对应的负责人，大多人只知自己负责的这块，调到别人那里面是什么个情况完全不知情。
简介
分布式系统会有一个对外提供服务的网关api，客户端请求到（负载均衡然后到）网关api，网关api根据路由规则会给到对应的应用服务去处理以及发送异步处理。在此之前，每个应用服务都要注册登记到服务注册监控中心，服务注册监控中心会把自己掌握的信息提供给网关api。至于应用服务，也就是业务实现的地方，主要的开发工作在此。不同的需求写不同的服务和业务逻辑代码，部分需求业务可能会用到缓存(Redis)和消息队列(RabbitMq)。每个功能模块下一般都写了拦截器，有兴趣的话可以去看看拦截器里面写了什么。
整个系统还应该会用到日志管理（方便整个请求链路的日志追查，一般是在网关的时候就生成日志号id， 层层往下传递）和性能监控（监测系统性能）模块。
