归一性与普适性的多重奏-浅谈技术抽象美

Posted 2022-09-16 CSDN 程序人生

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了归一性与普适性的多重奏-浅谈技术抽象美相关的知识，希望对你有一定的参考价值。

前言

我或许，

未曾亲身经历“长袖一拂元都门”的巍峨。

也未曾一览“云想衣裳花想容”的风月。

但我有幸能寻着唐宋大家的笔触，喃喃低吟中，

闭目涌入一丝别样的美。

是流苏云叠？是汩汩泉涌？亦是，亦不是。

就像李白的诗词，梵高的油墨，莫扎特的音符，王羲之的书卷。

既有意象，又切换着具象。

美存在于留有一丝的想象中，

Coding亦是如此。

业务重构的思考-抽象美是什么？

近年来，企业数智化转型不断加速的同时，想必每个程序员都切身感受到这样的痛苦：

比如短时间内需求变更、压缩工时，导致代码产出与设计背离；或者接盘了一个老项目，在语句与结构混乱、代码重复、没有注释的代码山中翻找“硬币”。

不美的事物会给人带来身体与心灵的双重疲劳，那么什么是技术之美呢？抽象的美感又是什么？

科学与艺术是不可分的，两者都在追求真理的普遍性。而抽象强调归一和普适，最终在多层次下实现降低业务复杂度。但只知理论方法，不亲身体验，对于欣赏抽象之美就会有偏差。

只有了解抽象的特点与场景中的问题，才会真正的明白什么是“抽象之美“。

归一与普适的多重奏-论抽象之美

抽象的创造美-归一性

如果抽象原则是笔和颜料，那么抽象设计就是绘画底稿，抽象结果就是最终呈现的作品。

近些年，随着微服务架构火热，很多单体架构的企业级应用改造为微服务，但是随着应用体积越来越大，管理越来越麻烦。特别是部署一套新环境的时候，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等问题让人困扰。

而Service Mesh 就是为此而生的经典抽象，下图是Amazon App Mesh的示意图：

亚马逊云科技（Amazon Web Service）提供了一个完整的解决方案，通过服务网格让服务轻松跨多种类型的计算基础设施相互通信。把所需要处理的通信场景降维到一定区间内。通过控件以配置和标准化流量在服务之间的流动方式。实施自定义流量路由规则，来保证服务在部署期间、故障后以及应用程序扩展时都高度可用。

在上述过程中，亚马逊服务网格抽象美体现在：将共性的技术治理部分剥离出来，彻底解耦应用与框架；并解决了异构开发语言问题，不同开发语言开发的应用，统一被通信代理模块接管。使得原本复杂的逻辑场景在一定区间内归一化。

抽象的美，在于进阶之后的创造与归一。

抽象的“具象美”-普适性

毕加索《牛的变形过程》

虽然抽象是与具象相对的一个概念，但是我们还是可以用“具象”的描述去体会抽象美。

抽象的美一部分在于它的泛化，可以将我们对具体事物的操作泛化到所有相似的事物上。

当我们总结事物、业务的规律后进行抽象，然后把抽象具体化，再泛化到其他事物、场景上可以有效减少我们重复思考的过程。

例如Amazon CodePipeline就是通过开发过程抽象，形成了 Amazon CodeBuild、Amazon CodeDeploy 和各种其他工具的持续集成或持续交付工作流。

这种抽象工作流在宏观角度上实现可运行、可观测、可治理、可变更。微观角度上可实现工作流顺畅和高效，各个环境自动触发和流转。

这样开发者、测试人员、运维工程师、IT工程师之间就不必过多地相互关联。使得整个流程更加轻盈/独立，并具有高度的普适性，而这就是一种抽象的美。

抽象的美不再是遥不可及的星辰，也许在我们工作的点滴中就已经“具象”地表达出来了。

抽象的层次美-多维性

抽象是一种思维模式，它是建立在封装之上的。抽象是从不同的角度、不同的层次看待问题。

层次越高，就越抽象。我们可以从过程-数据-控制进行抽象；可以从变量、函数、接口、消息传递、设计模式、应用进行抽象；也可以从视图层、逻辑层、物理层进行抽象。这就意味着不同层次的抽象下，视角是完全不同的。

而抽象的美加上层次，就像在读一本紧张刺激的悬疑小说，环环相扣、情节动荡，又像在读一本宏大的科幻小说，从微观到宏观，架空出一个完整的世界。

那么在我们的业务架构设计中，有哪些抽象之美碰撞出的火花呢？

接下来可以通过一个亚马逊云科技经典图示去感受下抽象的层次之美：

裸机抽象

裸机抽象使得应用程序可以利用底层硬件功能，因为某些功能在虚拟环境中不总是受到全面的支持。在这种抽象下，可以实现硬件上直接运行或在非虚拟环境中获得授权和支持的应用程序。

虚拟机抽象

虚拟机抽象我在另一篇文章中有所提及，我曾使用过Amazon Lightsail，在短短15分钟之内就通过Amazon Lightsail部署了一个简单的web应用。我只需关注客户操作系统及应用的中间件、应用程序等，无需过多操心管理硬件和虚拟机监控程序，包括它们的生命周期。

容器抽象

随着微服务的兴起，容器化成为一个标准的技术解决方案。

图示中的亚马逊云科技 ECS，它是一个具有高扩展性、高性能的容器管理服务，支持 Docker，无需安装、操作和扩展集群管理基础架构。而使用EKS 可以基于 Kubernetes 进行容器控制。

这种抽象使得用户从管理容器控制平面的重任中解放出来。

函数抽象

Lambda 是一个执行环境，允许亚马逊云科技客户运行单个函数。因此，无需管理和运行整个 OS 实例来运行代码，也无需在用户构建的容器中跟踪所有的软件依赖项来运行代码，这种直接驱动或间接驱动的抽象模型，使得函数级抽象变得十分灵活。

当我们无需管理运行函数之下的基础架构，无需跟踪物理主机状态和机群容量，无需修补运行该函数的操作系统时。不仅抽离出无关紧要的重活，并且赢得了时间和金钱。

在用户视角从底层抽象逐步上升到应用抽象的过程中，抽象的层次越高，用户的“爽点”体验就越强烈。站在最高层次看待问题，用户不需要去关心各个应用内部由哪些模块、构件组成，只需要将各个应用拼装来完成不同的任务。而通常系统的架构图就是这样，只画出各个具体的服务，关注服务之间的调用关系。一个服务，一个数据库，一个消息队列，一个缓存服务都只是一个圆圈而已。这就是一种归一与普适结合的抽象美。

“优雅”与“成本”的矛与盾

角色转换的思考

一个优秀的程序员或多或少都有一些自己的代码“洁癖”，也不乏追求高度与深度的集大成者。

无论是追求代码简洁之道，还是抽象之美，团队之间的个体差异都会对整个系统、产品的宏观视角产生不同的影响。

当个人行为的“优雅”上升到团队、组织、企业。当不同层次的抽象带来的“优雅”与“成本”变得难以决策，我们如何利用外部资源进行两者的平衡？

责任共担模式

亚马逊云科技的解决方案是责任共担模式-抽出更多的时间干好自己更擅长的事情。

这就意味着在抽象层级的叙事线中，我们抽象出了使用者和服务者这两个角色之间的行为集合。基于信任及共赢的原则，双方着重于更适合本身的事情。

亚马逊云科技着重于“云本身的鲁棒” – 亚马逊云科技保护运行所有亚马逊云科技云服务的基础设施。该基础实施由运行亚马逊云科技云服务的硬件、软件、网络和设备抽象而成。

客户着重于“云内部的鲁棒” – 客户基于亚马逊云科技云服务，只需关注着云内部的鲁棒。对于抽象化服务，例如 Amazon S3 和 Amazon DynamoDB，亚马逊云科技运营基础设施层、操作系统和平台，而客户通过访问终端节点存储和检索数据。客户只需要负责管理其数据（包括加密选项），对其资产进行分类，以及使用 IAM 工具分配适当的权限就可以实现完整的操作链路闭环。

矛盾的共生方案

当抽象的级别越高，云供应商就越能产生价值。我们可以在业务架构层中进行拆离，将“不擅长的部分”剥离出去，让擅长的人来做。当企业把寄存关系看为共生关系时，短期来看虽投入了现金流，但长期下来，团队可以集中精力去深入业务体系深耕。一方面减少人才流失，一方面无形中培养了差异化的核心竞争力。

追求抽象之美，也可以“两全其美”。