核心内容摘要
客厅里的温情：父母在，兄妹当面盖毯子的暖心瞬间
分布式系统这个东西到底该怎么去理解我刚开始接触这个概念的时候翻遍网上的资料要么知识点零散要么讲得太绕真到做项目的时候还是一堆问题。
今天我就仔细地讲一讲它跟你聊聊我的实际体会。
为什么需要分布式最早做项目一台服务器就够用了。
数据库、程序、文件都放在上面。
访问的人慢慢多起来网站开始变慢。
最简单的办法是换一台更好的服务器。
但是最贵的服务器也有它的极限。
更麻烦的是这台机器一出问题整个服务立刻就会停掉。
这时分布式系统就出现了。
它的思路很简单就是把一个系统拆成多个部分分到不同的服务器上去运行让它们通过网络协作共同完成一个任务。
现在大部分互联网公司都在用这套模式。
分布式架构主要应对哪些情况说白了主要是三件事。
分担压力。
请求可以被分散到很多台机器上处理不用堵在一个地方。
提高可用性。
哪怕其中几台机器不能用了其他机器还能继续工作保证服务不中断。
突破单台机器的限制。
我们可以把多台机器的内存、硬盘资源组合起来使用。
但你要注意这些好处都不是凭空来的你需要先处理好下面几个核心问题。
出现了哪些新问题
网络问题。
在单台机器上写程序调用一个函数结果很明确。
但在分布式环境里你的请求要通过网络可能会经过很多台机器。
网络线路会有延迟偶尔会中断。
你调用的那个服务可能没有响应也可能处理到一半自己失败了。
你必须接受一个事实在分布式系统里失败很常见而且往往是一种“部分失败”。
设计系统的时候如果不对网络和远程服务的不可靠性做好准备后面会非常被动。
数据一致性。
举个例子用户下了一个订单。
这个操作可能牵扯到订单服务、库存服务和支付服务它们常常不在同一台机器上。
你怎么确保这几个服务看到的数据状态是一致的如果订单服务成功了库存服务却失败了该怎么办很多团队会在这里纠结。
用过来人的经验告诉你这取决于你的具体业务。
有些业务动作比如更新用户的个人头像晚几秒钟被看到影响不大。
但像银行账户扣款这种操作就必须立刻准确不能出错。
你在设计每个功能时都要明确问自己这个业务能接受多久的数据延迟
系统复杂性。
如果出了问题你就不再能只查看一台服务器的日志了。
你需要跟踪一个请求在不同机器间的完整路径。
监控、调试、升级系统这些事情的复杂度都增加了。
我一直认为如果没有建立完善的监控就不要急着上分布式。
因为你需要监控基础设施比如CPU和内存服务接口比如响应时间和成功率还要监控关键的业务流程是否正常。
还有链路追踪工具应该尽早引入这对排查问题非常重要。
还有实际的成本需要考虑。
使用普通的服务器硬件成本可能降低了。
但是开发和维护这套系统的人力成本、时间成本会显著增加。
服务拆分开后团队之间的沟通成本也会上升。
这些都是在做技术选型时必须考虑的。
那具体该怎么设计呢
服务拆分是起点也是难点。
我建议你从业务本身出发。
一个服务最好负责一块相对独立的业务功能它可以被独立地开发、部署和扩展。
你可以想想修改这个服务的功能是不是主要只影响某一个业务环节
服务之间怎么通信用同步调用比方说HTTP或者RPC这种方式很直接但是容易因为一个环节慢导致整个链条都慢。
用异步消息就像消息队列服务之间的依赖会变小不过你需要处理消息会不会重复、顺序会不会乱这些新问题。
实际上这个问题没有完美的解决方案关键看你的业务更需要什么。
数据怎么管我的建议是每个服务最好拥有自己独立的数据存储。
服务之间通过定义好的接口来交换数据。
这样做带来的问题就是跨好几个服务的业务操作怎么保证数据最终是对的常见的做法有两种。
一种是采用分布式事务保证强一致性不过通常会影响性能。
另一种是采用最终一致性性能更好但业务逻辑需要处理中间状态。
你得根据业务的重要性来做选择。
在实践里为了确保这种跨源数据交换的可靠和高效我通常会借助一些专业工具。
比如我团队在用的FineDataLink这个数据集成工具它就能很好地处理这类定时或实时的数据同步任务把我们从复杂的脚本和手动检查中解放出来。
容错设计必须做。
你依赖的其他服务都可能出错网络调用都可能超时。
所以在一开始你就要把重试机制、熔断策略、服务降级和超时控制这些设计进去。
核心思路就是预先认为外部依赖都可能失败需要设计好应对逻辑。
学习路径建议如果你刚开始接触别一开始就去读那些很难的论文。
从使用开始先去用用Redis集群或者Kafka看看它们提供了什么功能配置项是什么意思。
动手搭建试着在本地自己搭一个Zookeeper或者Etcd的小集群动手操作一下直观地感受节点的加入和退出。
读经典文档之后你可以去阅读一些成熟系统的设计文档比如Kubernetes它们讲解核心概念的方式通常比较易懂。
深入核心问题最后再有针对性地去研究分布式事务、一致性协议这些专题。
因为你有了前面的实际感受会更容易理解它们。
小结分布式架构只是一种处理特定问题的方法。
如果你的业务量不大一台服务器足够那就没必要用它否则只会增加不必要的麻烦。
但如果你真的需要它的话你要记住分布式系统的核心其实是一套在复杂、不可靠的环境里依然能让系统稳定工作的工程方法。
它的目标是当某些部分出错时整个系统还能提供服务。