企业应用架构 - 实践

[!TIP]
记录的企业应用架构实践的思考

• 企业架构的实践宗旨
• 技术推动业务
• 应该怎么做
• 技术和市场

实践的宗旨

• 架构设计核心目标是支持业务，有些时候不合理的存在是合理的。
• 应用架构存在的首要目标是支持业务，很多成长性企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。这种情况在互联网型企业更为常见。
• 业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。

技术是推动和适配业务

在创业初期，公司正在起步，很多业务继续推向市场以及试错。一开始别尽是整一套高大上的超级架构。超级架构得有业务量、人员、成本、时间的支撑。如果架构师一味的为了架构而架构，脱离了公司的实际情况，脱离了当下业务的实际情况，那么整出来的架构就是空中阁楼。或者能够整出一套满足和适配未来的业务机构，但是市场早已过了需求期，那么此时的架构也是一文不值了。

应该怎么做

优秀的架构要做到的是，跟上级和老板沟通好未来的业务体量，市场情况，公司规模。然后根据现下的公司情况、人员情况、资金情况、项目落地周期等进行综合考虑和权衡。能够站在业务的角度，加上有技术的拖底，能够从大局的角度，在业务发展的每个阶段适配技术架构，以及尽可能保证后期不需要重构，技术和架构能够随着业务的开展平滑升级，减少技术负债。

再拓展开来，在公司业务发展的各个阶段，使用那哪些技术，要把资金成本、推向市场所允许的项目周期、用哪个技术栈、程序员好不好招人、程序员好不好培养、招来的程序员能不能够适应选中的技术架构等等统筹考虑进来。

比如说，不同的情况下。例如，公司能够提供50万的资金成本，项目周期为3个月，所在城市为二三线城市，java/php程序员相对好招；或者能够提供100万，项目周期为2个月，所在城市为一线城市，go程序员相对好招；或者能够提供100万，项目周期为6个月，所在城市为二三线城市，但是所需的是开发网络中间件，也需要用go开发，就要有培养go程序员的准备；还有等等其他实际情况。合格的架构就要根据公司的实际情况实施项目落地的计划。

技术和市场

两种说法：

• 技术不是决定性因素，市场才是王道。技术辅助业务
• 技术能够成为市场。那么技术就是唯一标准。技术决定业务

技术辅助业务

拿最经典的TP框架来说。很多phper都知道，TP框架很简单，入门超级的快，但是从技术的角度上看，这东西看起来不是那么的高大上不是那么的牛逼。一些刚入行的phper觉得TP框架很low，用这框架感觉掉价，但是又很困惑，为啥看起来low的这么一个框架，却能够有那么大的市场。

原因就在于，80%以上的企业都是初创型的中小企业。这些企业在创立初期，无论是人员、资金、技术等各种资源都是欠缺的，但是又要在市场上快速的推广产品，赚取利润，抢占市场。保证公司在成立初期能够活下来，而TP框架，就是很好的满足了这点需求。所以TP框架成了众多初创企业的优选，这时候技术就是辅助公司开展业务的一个手段，而不是决定性的因素。

所以，从业务的角度来理解技术，也就能明白技术在业务的前提下，应在处在一个什么样的位置。所以，TP框架从技术上看起来很low的样子，从适配市场的角度来看，其实一点也不low。

特别说明：当然，相信TP框架作者的实力，也可能把TP框架打造成很高大上的框架。

技术决定业务

技术决定业务的情况有很多种，这里只记录关于基础设施的思考。

当一个技术能成为基础设置的时候，这时候技术就是唯一的标准，成为开展业务的主要因素。
什么意思呢？看几个例子就知道。安卓系统，k8s，Linux操作系统等等这些技术，能够成为发展一个技术生态的基础设施，换句话说，就是能够成为更上层的经济业务建设的基础，这时候技术就是占主导因素。

讲的更直接一点，安卓成了各大手机厂商的手机操作系统;k8s衍生出很各大公司的版本，例如：Rancher的k3s，sealos等等；Linux更是一片繁荣，有Redhat系列的、有OpenSUSE的、有Debian的等等，Linux已经成为这些商业化公司的基础。

在这个时候，技术就是决定了业务