初探分布式

什么是分布式

分布式一直作为一个看起来很高大上的名称，特别是给外人介绍什么是分布式时，貌似也没有什么通俗好理解的介绍，基本就是顾名思义，对应单机的反义。
分布式不是一个具体工具和服务，而是一种模式，或者说是解决一大类问题的一种方法。这种模式遵循一定的规则（cap理论），并通过多种不同工具和算法协助来解决一些特定场景的问题。一般就是以比较良好的扩展性来提升系统的可用性和系统容量（容量包括存储、并发量）。
也因为这样，分布式的学习门槛和天花板相对比较高，要能知道各种各样的，要懂得一些算法，才能比较好对某类场景问题提出一个比较合适的方案。很多人参与分布式的实践，却没有了解背后的根源。只懂得了一些技术名称和工具使用。
分布式技术是当前互联网各个系统框架的基石，基本上每个互联网企业发展到一定程度都离不开它。同样的，作为开发人员，特别是后台开发人员，分布式是一道必须要迈过去的槛。

分布式的优缺点

分布式和集中式是对立的，但是不代表分布式就比集中式好，目前大部分的系统都是两者混用，分布式用来提高可用性和性能，集中式用来解决一些互斥，一致性的问题。
上面提到了分布式的优点，再看看分布式的缺点：

1. 因为使用了分布式，必然增加了维护的成本，例如采用微服务架构，那少不了要一套自动化的运维管理系统来管理各个服务和数据。
2. 在服务的设计会变的复杂，要一致性、和可用性等权衡。
3. 分布式增加了吞吐率，但是单个协议的响应时长没有减少，可能还会变长。

分布式技术栈

先列下个人理解的分解图，从分布式的作用和功能，到实现该功能相关的工具和算法。

1.微服务。
2.分布式要做到计算的分布，其中负载均衡的几种算法也比较关键。
3.服务治理、名字发现、容灾。
4.选主的几种算法及实践。

具体的组件和工具：
1.存储这块，redis、mysql、leveldb的了解。数据分区、数据镜像、数据同步这些都可以算分布式的具体实现了。
2.消息队列，kafka
3.RPC框架,thrift、brpc、grpc等
4.分布式框架，zookeeper
5.docker，k8s
很多组件单独拎出来跟分布式貌似不搭边，但是都是目前后台系统实践里边必不可少的组件。
例如redis做缓存来降低响应时间，提高性能、消息队列来消峰和解耦各个服务之间的容量z依赖，这些组件结合微服务，才共同达成了分布式最初的目标：提升可用性和系统容量。

最后，摘抄下左耳朵耗子哥文章中的：
应用网关，服务发现、配置中心、健康检查、服务监控、服务治理（熔断、限流、幂等、重试、隔离、事务补偿）、Tracing监控。千万不要觉得，整几个服务RPC一下，加个缓存，加个队列，就能叫架构，那只是系统集成罢了

真正的企业级架构，其中并不仅仅只是RESTful API或RPC，还有各种配套设施和控制系统，比如：应用网关，服务发现、配置中心、健康检查、服务监控、服务治理（熔断、限流、幂等、重试、隔离、事务补偿）、Tracing监控、SOA/ESB、CQRS、EDA……
千万不要觉得，整几个服务RPC一下，加个缓存，加个队列，就能叫架构，那只是系统集成罢了！

个人觉得，如果能把上述一些配套设施和控制系统搞清楚了并且理解对应的实现方案的优劣，就离分布式大牛不远了