浅谈分布式架构

Posted 2021-04-14 悠爸实验室

Question：为啥会想到写分布式架构？

首先，刚过去的2017有几个东西特别火，一个是机器学习，一个就是微服务。

前者说的机器学习，学的其实就是数据，而数据还有个孪生兄弟叫算法，引申开来有个东西叫人工智能，不管是机器学习还是人工智能，放在再早几年，那可是很高逼格的技术，但是，这些技术现在正在逐步“平民化”。当然，和其他技术一样，关键是因为有了土壤（各种应用和使用的场景），所以，这些原先看似只是Lab里的东西，已经开始慢慢进入到耕耘土壤的广大码农的日常工作中。

呵呵，可惜，我对机器学习不太熟（最近开始学习），更加不懂人工智能。但是说到微服务，却真是看着它一点点地发展起来。众所周知，微服务就是分布式架构的一种，目前业内有太多的大小公司都是基于这样的架构进行应用的开发。而且围绕着这种架构的基础设施也越来越丰富。

技术往往就是如此，解决开发人员的问题总归显得比解决实际业务问题更有意思

但这只是一方面，为啥写分布式架构呢？因为最近被布置了一个作业，梳理下公司早年的技术演变历程，所以就当练练笔，理理思路。

在十几二十年前甚至更早的时候，我们说到软件，想到的都是在自己的电脑上可以运行的应用程序。前段时间我收拾老房子的时候扔掉了一大堆的2000年那会的光盘（电脑之家、程序员等等杂志附送的光盘，或者是当时的一些软件盗版光盘）。呵呵，现在想想，那个年代开发人员其实早期有个不成熟的认知：软件开发，就是做这些可执行程序的，以至于在第一波互联网泡沫的前后几年，哪怕做网站的开发工资再高，但好像他就不是在做软件开发。（这个高工资也随着第一次泡沫的破裂而破裂）

当然，现在已经不同了，我们也不太关注什么是软件了，更多被提到的就是：应用、服务。而在分布式架构开始成为行业的主流架构之前，其实单体应用其实也存在了很长时间。包括上面说的可以运行的程序，以及网站。我现在公司的网站，最开始就是一个典型的单体应用。

其实现在回过头来想想，单体应用相比较于我们现在开发的一些程序而言，其实也有诸如以下这些优点：

1. 学习曲线更多是面向于领域知识

2. 设计更接近业务

3. 系统架构简单

4. 方便测试和部署

5. 维护简便

听上去好像这些优点都跟现在我们实际的开发实施过程中遇到的某些痛点相对应。我们现在偶尔会听到说：

1. 这套RPC框架的使用还是需要花一点点学习成本的

2. 就知道关注基础设施的设计，为什么不好好把业务模型梳理清楚

3. 有个服务挂了，我们都没法进行测试了

4. 某个底层服务挂了为啥运维都没有及时发现并通知我们

那又是什么让分布式架构取代了单体应用呢？

拿我现在的公司的情况来说，幕后的推手其实就是以下两个主要矛盾：

1. 不断规模化的业务发展趋势与系统本身的容量与支撑能力之间的矛盾

2. 不断上升的服务质量的需求与系统可靠性和稳定性之间的矛盾

大概3年多前，当时内部的季度复盘都会把系统问题作为几个主要的投诉问题之一拿出来讨论，正是在那段时间里，一个被当时称之为“服务化”的事情被提上了日程。而这个服务化其实就是建立在分布式服务的架构基础之上。

但是这并不是一个顶层设计下的产物，在互联网创业型公司里，这更多是一种尝试，这里提一个在上一篇我转发martin fowler的视屏里的一个词：trade off。世界上没有一个技术方案是完美无缺的，很多时候有得就有失，这就是一种交换。分布式架构通过scale out（解决容量问题）和冗余（消除了单点）带来了高可用和高稳定，其实也带来了以下这些复杂性的增加：

1. 基础架构带来的复杂性：
   分布式架构引入了很多偶发复杂度，例如当服务不可用及其他一些系统异常时的异常处理复杂性等；另一方面，不同于单体应用的组件级的分层，分布式架构的分层设计对架构设计能力的要求更为明显；最后还有一个最大的问题：the price of high reliability is…..the lack of consistency，一致性的问题带来的就是分布式事务的问题

2. 开发与调试的复杂性：
   这一点从开发人员的基础开发环境的变化可见一斑

3. 服务与服务之间的调度管理的复杂性：
   这是为什么要引入服务治理的原因，我现在公司在这方面在早期依赖的是“人肉治理”，成本之高是一般人无法想象的，这也是为啥早几年经常看到大促前通宵加班的原因

4. 部署的复杂性：
   3-4年前，我自己就是运维兼DBA，写一套半自动化的发布脚本花了我2天半的时间，而现在如果没有一套可靠稳定高效的集成发布系统，那简直就是噩梦。记得我们早期服务化的时候，同时还伴随了应用的拆站，很多时候大家加班到半夜，其实只是因为发布一个版本花了4个小时

5. 运维的复杂性：
   一句话，一个IT工程师和一个运维团队的差异，体现的就是这个复杂度的差别

很显然，这些复杂性带来的问题，对于一个年轻的创业团队来说，就是伴随而来的一个个坑，过去几年就是在趟平这些坑的过程上走过来的，当然，有些是主动趟平，有些则是先踩坑后埋坑。

BTW，有哪些坑，怎么趟平，以后有机会具体展开说，甚至可以让团队里实际负责这块的人写出来，然后拿来做个分享，呵呵。

分布式架构的演化

其实我一直认为最初的服务化更多的是一种由单体应用向基于SOA的架构的转型。而真正进入微服务的架构也就最近一段时间。以下，仅从我所在的团队经历的架构演化来谈谈我对分布式架构的一些理解。

SOA强调分离服务和使用服务的调用方。这个分离的本质是减少对实现的依赖，同时将这种依赖转化成一种抽象，也就是基于服务的契约。回头看下4年前我所面临的单体应用时的瓶颈，之前我有篇文章里说过，我们的代码最多的时候有160多个projects，单体应用的代码库集中且庞大，同时设计不合理（其实更多是快速迭代下的新老架构并存）还可能导致大量冗余形成的痈肿，就在这样的情况下，将部分核心业务分离出来，并以服务的形式与原有的单体应用进行集成，这就是早期服务化的雏形。后来，越来越多的业务被分离出来，短短1年半，不断新增的服务就使当时基于脚本的半自动化发布过程完全无法应对快速开发的要求了。

前面说了，我们团队过去几年的服务化不是顶层设计的结果，因为当初的服务化过程的设计原则是相对模糊的，更多是凭主观经验，但关于什么适合作为一个服务，什么粒度的服务是最适合的，服务的协议标准是什么，以及服务集成的技术选型的深入分析，这些现在来看只是某个人或某几个人快速做的决断。

当然，快速迭代的互联网创业公司，难道不就是这样的吗？等你想明白了，茶都凉了。

那么如果把时间倒退回去，把这个服务化的事情再来一遍，首先我们是不是要先看看什么是SOA的基础原则，或者了解下基于面向服务的架构，有什么特征？

基于这几年的实践，我总结如下（有不足或错误的请留言指正）：

1. 标准化，显式化定义服务职责的通用接口

2. 具备抽象的特征，这个特征包括两个层面的含义：一个是可重用，二是封装实现，不暴露细节。之前有一篇讲领域建模的抽象时也提到过，好的抽象的一个特征就是极简，即指暴露该暴露的。

3. 服务的粒度需要精心考虑，同时服务需要足够内聚且完整

4. 其他还有诸如必须无状态等

其实上面这些看起来也不是什么“精致”的方法和原则，而且貌似我们实际做得跟这个差不太多嘛。

SOA这种架构更多是从早期单体应用盛行的时代演化出来的一个东西，就好比细胞裂变一样。最开始提出这套架构的IBM，其面向的大多是企业应用的场景，早些年我们都说企业应用重，互联网应用轻，除了企业应用很多业务逻辑复杂以外，还跟大量的模式和基础架构都是从企业应用发展而来的有关。早期IBM提出的SOA，基于SOAP、XML的协议交互，以及服务集成所用到的企业服务总线（ESB），相比现在分布式架构普遍使用的Restful、Json和基于消息的Pub/Sub的消息总线，现在很多人看来肯定是非常的难用！但是这些设计的变化，也不是顶层设计出来的，就是在传统的SOA架构给出的一些建议以及实现路径的实践过程中不断演化，才有了现在的这些“合适”的实现。

SOA？微服务？

无论怎么说，基于早期服务化的几年时间，我所在的团队确实减少了整个业务系统的逻辑耦合，但是要说早几年的SOA和现在正在进行的微服务，其实都是一种分布式系统架构，或者更准确地说是分布式服务架构。更好地理解这种架构的优缺点，以及这种架构过去、现在和未来，其实对于如何更好地在其之上进行设计、开发系统还是有很大的帮助。由于去年开始我转去负责另一个非电商项目，可以让我有机会跳出来看原有的电商项目的分布式架构的演变以及相关的一些技术和方法。

如果说早期的SOA是为了分离（有人说分治，我觉得还不到治的地步），以及进行一定程度的抽象，让一些基础业务可以通过独立的服务被重用，那么正在进行的微服务，是为了提供更好的弹性，以及更合理的职责分工。而作为一家创业公司的早期技术团队，也许没有那么多时间去做精心设计，那在经历了几次裂变之后，这张网已经把很多东西连起来了，接下来就是精心编织的过程了。

总结