大话分布式服务——初识分布式服务

最新推荐文章于 2020-06-27 21:43:47 发布

xupeng874395012

最新推荐文章于 2020-06-27 21:43:47 发布

阅读量292

点赞数

分类专栏：分布式文章标签： java 分布式微服务组件化云服务

本文为博主原创文章，未经博主允许不得转载，转载请附原文链接说明出处。

本文链接：https://blog.csdn.net/xupeng874395012/article/details/105648557

版权

分布式专栏收录该内容

4 篇文章 0 订阅

订阅专栏

初识分布式服务

简介

大家好，我们开始第一章初识分布式服务

正文

本文以初识为题，旨在初步介绍分布式服务的相关信息，给读者一个初步的印象。那么怎么来解读分布式服务呢？分布式服务是计算机系统服务中的一种概念，那什么算是分布式服务呢，这个要从软件系模式起源来介绍了。一个成熟的分布式系统总是经历过了很多人的辛苦付出，经过了N次的迭代发布之后才产生的。本文以一个小伙伴创业最后成就自我的例子来介绍下系统发展历程，给大家体会一下什么分布式的由来

创业期

我们可以想象一下，假如当前有三个好朋友商量着要不我们创业吧，做一个电子身份证怎么样。就这样三人一拍即合开始做，就这么一个单纯的数据管理功能，那我们的系统初期肯定就搭建一个web系统包括用户的正常的登录，信息新增和变更，然后对应的有一个数据库的实例来进行数据的管理基本上就可以够用了

发展期

随着企业发展，开始跟其他的业务来合作，那比如说公司跟某店合作，开始管理用户的收货地址和联系信息。随着业务增加，发现数据查询量越来越大性能也越来越差，怎么办呢，加缓存吧，noSql的redis开始搞进来。

随着发展使用人数的不断增多，那我们的数据越来越多，然后开始有用户反馈系统越用越卡了，怎么办呢，系统响应越来越差了，那这么继续下去，用户肯定是会越来越少呀。那就开始找问题呗，发现现在数据库的数据总量记录太多了都好几百万条了，然后发现有很多是历史已经删除的数据了实际是用不到的，那好办呀开始数据结转呗

到现在为止，系统还一直处于最原始的垂直架构上，直上直下一大坨，但是后来跟某宝合作了，最先出现的问题就是对外支持的收货地址信息性能出现问题，怎么办？单机跟不上了，那就多机，前面加个负载。然后就么继续搞，这就开始引入了集群了

然后系统业务继续发展，主要对外的就是查个收货地址，官网注册修改信息，其实跟这个查询没啥关系，这不是啥问题，就是资源浪费，因为每个部署的应用都包括了公司所有的业务服务，实际上是没有必要的，那就拆开呗。从这就开始系统拆分了，这个阶段应该就可以理解为进入了分布式服务的初级阶段了，这会业务简单不做赘述，就先按业务，把官网注册维护数据和对外收货地址查询拆分成两个应用，然后官网部署一台机器，查询部署个10台

拆完了之后，后来缓存扛不住了，怎么搞？单机不行，分流呗，引入缓存集群分片来解决查询单机瓶颈问题。

后来发现查询信息部分流量进入数据库，影响数据库的性能，然后导致有些时候，新增用户失败和更新信息不可用。怎么办？读写数据库共享有问题，怎么办拆，引入读写分离。

一段时间之后，用户量继续增长，写库性能下降，怎么办？分库分表，给分2个库，一个库分个20个表，基本上够用一阵子了。

成熟期

现在我们再去看那个企业，发现公司已经不满足于给别的企业提供，地址管理服务这么简单了，开始自己搞电商了，那电商互联网产业在业界就就简直是秒杀、大流量、高并发的代名词了，

然后开始公司有自己的进销存系统，开始有商品、订单、交易、营销等等一大堆的东西，然后这个系统也面临着它的继续进化，

首先随着系统业务的增加，开始有了更多的系统分布，那这些系统已什么维度进行拆分就是一个很大的学问了，如按业务纵向拆分内部闭环、也有的主张横向业务拆分。这里我们应该是开始了解微服务了。微到什么程度，这个是一门艺术，个人感觉这个没有放之四海而皆准的方案，还是需要结合实际的业务来做，这部分让我概括来说，真的是如三国说的“天下大势，分久必合，合久必分。” 发展到这个阶段，服务治理也就显得尤为重要了，RPC框架，依赖图谱，调用全链路追踪，弹性伸缩这些也就是成了要具备的能力了

再换个角度去介绍，有了商品，那就肯定有商品定价、竞价分析等一系列的能力，数据搜索引擎、千人千面推荐之类的，以及卖货库存扣减超卖，退货恢复库存等等，然后应该也会随之遇到的分布式事务呀、最终一致性呀，这些也就很容易的被引起注意了，没办法啊，不注意就该被坑了。

说完库存类的问题，我们再聊聊交易方面的问题，每年的618 双十一，时不时的可以看到爆出某某平台的零点不能支付了等等的问题。这种的问题究其根本原因那就是交易的全链路太长了，然后在高峰流量情况下部分节点出现了问题，导致的系统不可用，那为什么又能快速的恢复呢，我们就这个问题来简单聊聊，我们作为一个消费者从平台选购商品，要经过商品展示的N多查询服务，然后加入购物车之后要经过购物车管理服务，然后我们要选择最适合自己的优惠服务，然后再提交订单之前我们还要选择我们的收获地址，最终提交下单支付，支付的时候我们要选择支付工具，要提交支付要经过密码验证，甚至有可能还要经过风险验证，我们感受到的就有这么多环节。然而在业务系统内部服务中，它们会经历N多的节点之后才能完成我们的一笔订单交易。这其中任何一环都可能造成我们的系统失败，那么当发现失败之后怎么能够快速恢复呢，这个地方我们就不得不提到熔断降级类的手段了。

我们再换个场景聊另一个话题，假如说公司要搞活动，10块钱秒杀一台电脑，此活动的关注度已经达到了几千万了，但是秒杀奖品就20个，怎么搞？这个场景要提的是预热/功能前置、限流、名单等这类的维度，虽然说这类并非分布式独有。