低成本通常被认为是架构设计过程中的一项约束，或者说低成本也是架构设计中的非功能目标之一，它跟高并发、高性能、高可用、安全性等非功能目标一样，一直贯穿架构设计过程的始终。不同的是有些企业会把低成本以明确的目标方式提出，而有些企业则将其视为约定俗成的原则，只要不是偏离太多则默认算是达成了。
与高并发的加机器扩容刚好相反，低成本在硬件上则是尽量压缩减少服务器的数量以降低成本。压缩降低服务器数量的同时，还要提升性能，这怎么能做到呢？答案是创新。所以低成本的实现关键在于创新采用新技术，但是新技术也意味着要冒一定的技术风险，这样系统的安全性或稳定性上可能又会有所影响。另外新技术对人的技能要求也会升级，意味着过去的技能与经验也需要同步升级，这些因素都可能反过来又影响了项目的进度与质量。
低成本对大型系统的影响在于大基数下的小比例性能提高也能节省不少的成本，比如说某个系统共用了1000台云主机，每台每年费用为1万块钱，那一年就需要1000万，采用了新技术后，系统的性能提升了20%，那就能节省1000*20%=200万。再比如某个使用了XML作为接口协议的系统固定带宽用了20Gbps，改为JSON作为新的接口协议后，由于报文平均缩小了30%，那相同条件下只需要14Gbps的带宽即可。系统规模越是大，细微的技术创新引起的性能提升都能节省很高的成本，所以低成本通常会在系统规模发展到一定的阶段后才会被提出来重点考虑。其实上面的例子如果是对于突发流量能用云计算按量付费或云原生的弹性伸缩还能更一步节省成本，但这都严重影响了我们的架构设计方案。
低成本除了硬件成本外，软件成本更是不容忽视，对技术人员来说一个最常见的例子是要不要使用商业数据库，比如Oracle数据库。对早期很多大型电信、金融企业来说过去很长一段时间是实现系统的信息化而且单客价值也高，即便购买Oracle这些昂贵的商业数据库，收入也能很好地够覆盖成本。但到了互联网时代一切悄然发生了变化，许多互联网公司采用长尾模式作为其盈利模式，不但单客价值低，平均单条数据的价值也要低得多，在这种情况下如果继续使用Oracle那成本就太高了。所以在分布式数据库普及前很多互联网公司采用了Mysql + 分库分表的廉价方案。在支持单表记录数上，Oracle要比Mysql高一到两个数量级，通常认为Mysql单表记录数达到千万级就要考虑分库分表了，而Oracle单表记录数达到亿级也非常见，甚至在硬件配置不错的情况下单表十亿级仍然能高效快速查询。在多表联合查询上，Oracle更是要强大得多，超过5张的大表联合查询仍然非常高效，这是Mysql这些开源数据库短期内难以媲美的。在Oracle的长期培育下，涌现出一批以数据库为中心的程序员。他们编写的代码主要面向数据库，并且依赖于复杂的SQL语句来实现业务逻辑。
相比之下，互联网程序员由于受限于性能较弱的Mysql数据库，编写的代码更加小心谨慎，努力避免给数据库带来过多压力。在分布式数据库普及之前，在后端编程领域，我认为传统程序员和互联网程序员最大的区别在于前者是长期是在商业数据库如Oracle的呵护下进行编程，而后者则是呵护着羸弱的开源数据库如Mysql进行编程，所以你能在用Oracle的传统项目中看到上百行的SQL,而在用了Mysql的高并发系统中总能看到大量保护或节省数据库资源的优化技巧。
不同的企业类型类型面临的低成本压力显然是不同的，同样是支持10万的QPS，民营企业和大型国有企业能付出的成本也大不相同。但我认为只要未来是在充分的市场经济下，收入必然是要覆盖成本的，只有这种情况下的的架构才能长久才能持续。很多著名的互联网企业发生的P0线上故障看似是技术问题，其实倒不如说是在低成本限制下的技术问题。对互联网公司来说硬件资源的日常的利用率高是常态，而灾备也多半是互备，很多时候只有当故障发生时才知道真正能用的灾备资源是多么的捉襟见肘。相比之下某些大型金融、电力的系统平时的硬件资源压力则要低得多，而灾备的资源更是充裕。所以不同的企业有不同的低成本目标，不同的低成本目标对架构师的挑战也会各有不同。
低成本实现依靠创新，所以有了新技术的出现，互联网企业面临着更高的低成本压力，所以有更多的技术创新。比如正是数据库的like模糊匹配对全文搜索的支持不足，所以有了ElasticSearch。正是数据库对高并发读能力的支持不足，所以催生了NoSQL如Redis、Memcached 等技术。低成本目标的实现应该是一个持续的过程，从长远来看只有最终达到了收益覆盖成本才是稳定的状态，2023年在互联网企业中流行的降本增效，也可以认为是一种包括了人力资源的低成本目标，是对过去粗放式不计成本的增长的债务偿还。但是在实现这个目标的过程中有些企业操之过急推之过快，导致了出现了不少的问题，导致相继出现了被网友戏称“降本增笑”的事故。
为了实现低成本，对于实力雄厚且领先的大企业来说，往往需要通过引领创新来实现，难度很高。而对于多数的普通企业来说，更多的是通过引进相对成熟的新技术实现，难度要低得多。对于我们架构师来说，保证系统的技术架构持续略微领先于业务发展除了更好的支持未来的发展之外，还能以更合理的成本来实现目标。作为架构师，需要不断关注行业的最新动态和技术趋势，结合企业的实际情况，做出恰当的技术选型和架构规划。在保证系统技术架构略微领先的同时，也需要合理匹配成本，确保技术投入与业务发展的平衡，实现最佳的技术与商业价值的结合。
