最后更新2021/08/25
人工->脚本->批处理->微服务->公有云->公共IT基础设施 代表作品：Daniel Heilig手机拍照作品，腾讯云，阿里云，amazon，azure
|
+->综合网管->私有云 代表产品：冷军《小姜》，HANA，Exadata，iSeries
Daniel Heilig手机作品
图片引自：https://www.sohu.com/a/437592302_375507
冷军《小姜》
图片引自：http://collection.sina.com.cn/auction/pcdt/2019-11-18/doc-iihnzahi1636529.shtml
齐白石《虾》
图片引自：https://baijiahao.baidu.com/s?id=1602679190287159348&wfr=spider&for=pc
对应的设计策略是专业化产品：Redis，MongoDB，ElasticSearch，MQ，硬件Firewall，专用VPN设备等等。
在业务最初始阶段，设计师都是在摸索中前行，此时的设计主导是快、简、全。用最简单实现，用最快速的时间，完成最全面的功能覆盖，以进行市场试探，如果最终取得好结果，通过循环迭代，一代一代发展，逐渐把简单的功能完善，全面覆盖的模块进行修建，符合市场期待的功能增强，不符合市场或者自己做不出特色的功能裁剪掉，用别人在此方面做得好的产品替换掉。最终自己产品在特定应用场景垄断特定的功能。
不同的主导思路导致最终不同的产品。同样，不同的主导思路产生不同的设计结果。有钱，大款，想一劳永益（当然不可能有绝对永益，只是后续麻烦相对少些，注意相对二字）的设计方案是多采购硬件化、集成化、单一厂商来源的整包产品，甚至将管理服务也打包在采购之中。给钱多最大的优点并非设计好，实现强，功能佳，而是顶得起缸，背得动锅。有道是IT是玄学，想不宕机要拜佛，机柜里挂耶稣十字蒙难，机柜上摆佛祖笑口常开，朝麦加标记方位，各方人马都不能亏待。
预算（何止）不充裕，喜欢自己动手丰衣足食（又无需我动手）的方案则是”软“实现为主，自己拼拼凑凑，防火墙，软的，firewalld；数据库，软的，结构化、非结构化搞两个；中间件，软的，开源闭源一起上；搞高可用，容灾，手工切换不香么？2千里外找俩人关小黑屋，每天快递一盘6T磁带过去，专门手动恢复数据，人工做回滚，需要切换就拔插网线，一年几千块钱搞定的事情，还要啥裸光纤波分复用存储复制？什么，人员工资？专门招当地偏远山区进城来的码农，俩人一组，换班回家乡工作一年，包吃住，招10个人足够天天写流程，干5年了。5年之后，IT技术都翻盘了，换人比换机器容易多了！但是，删库跑路咋办？篡改数据咋办？关键时刻不顶用，撂挑子咋办？我也不知道咋办，这些是管理风险，设计之前，先把丑话说前面。
降维封装。这个方案是把设计系统分为一个一个独立的黑盒子，对外只有输入、输出，并保持不变。好处是能够在实现同样功能的不同实现之间自由替换，可以更灵活。而坏处是往往找不到严格按照自己要求（已成公共标准）实现的产品，那就要自己做warp一类的包装程序或者功能，自己做集成整合，无论工作量，可靠性，可维护性都很差。对于以前只有商业软件存在的时代，设计者不得不委曲求全，商业软件、硬件往往没那么灵活，而且自身就是事实上的黑箱，想要拿来就用是不可能的，除非改变自己已有体系去配合商业产品。在现在开源时代，事情逐渐往好的方向发展，即使很多厂商自己开发的技术，也以开放标准的形式免费供大家使用，即使竞争对手厂商也会采用同样的标准。降维主要面对多厂商、多组件整合的情况。
升维补偿。有降维，把一个个子系统变为黑盒子，也有升维，把全部系统整体变为一个黑盒子。与降维方案对比，升维目标以效率优先，同时”相信“系统能做得很好，故障、失败、错误是极少数情况。例如，如果降维实现，则操作的每一步都要考虑错误恢复，否则就需要前序、后续环节有相应的补偿措施，做不到透明实现。升维实现则是把所有的补偿、恢复、确认放到最初始和最结束点，只要终审，中间过程一概忽略。这样做中间组件的功能压力最小，可以全速工作，最简化任务处理，但是缺点是故障侦测，错误恢复，可恢复的数据都会变得很差，技术上称为数据恢复颗粒度太大，如果系统本身经常出现故障，那么还坚持这种设计就是灾难设计者，无异于抱薪救火。
算法导论。任何计算机专业毕业的人都学过的，拿过来就用好了，不要想着很稀奇古怪的算法去解决问题，首先没必要，我们能遇到的大部分，甚至所有的问题都可以归纳到最基本的那几类，解决问题方案也差不多就是那些，足够了；其次是想一想午餐的价钱。不免费。四轮马车比两轮马车好，几乎毫无悬念：两轮需要马匹负重，载重量有限，四轮可以无视负重问题，拉力摩檫力不够，多加挽马就行了。而两轮，辕马负重能力决定了车的最大承载力。那么，为什么中国古代5000年没研究出4轮马车？还要近代从欧洲引入？因为四轮并非完美无缺阿！反而是缺点多多，特别是在中国当时经济、技术条件限制之下，反而两轮是最佳的。举例来说：中国的蒙古马普遍矮小，单匹拉力（摩檫力）不够，车辆重载，需要多匹马一起拉，并不能提升马的效率。四轮马车前后转向需要有差速装置，否则车轮，轮轴磨损严重，加工精度要求更高，无法单独用木材实现，需要有足够的铁器加工精度才可以，中国相关技术到明末才有提高，很多还都是外来的。中国尽管平原不少，但更多的是丘陵，道路崎岖，从秦朝开始修官道，直到清末其实大部分道路还都是土路，而且距离超长，在这种路上，四轮车越野能力远远不如两轮。欧洲的四轮多用于港口到城镇内货运，道路都是石头等硬质路面，距离近，平整，要求重载（欧洲马很高大，载重能力一匹顶4匹）。大部分时候，不要嘲笑别人傻，自己作为一个阅历不深的设计师，架构师，先听听，看看事实到底如何。没有选择、试探过你所谓聪明的方案的原因是：选择这种方案的人早就被淘汰掉，棺材板都烂了。
反过来说，如果想解决什么现实问题，在不考虑综合结果，特别是搞个差不多的，不完美的方案，只想做临时修补的前提下，例如缺点数据，某些时候性能不好，设备故障不能断点重做等等，”悄悄“引用一些简单的算法，就可以解决99%的需求，惊艳一下。
我会回来的！