最近参与了几个项目的性能优化，总体来说各个项目都有所提升，能够满足用户使用需求，但是这个过程耗费了大量的人力、物力资源成本，主要原因有以下几点:
- 系统本身没有任何参数指标，这一点其实是大多数系统存在的问题，打个比方我作为乙方给甲方做了一个软件，交付完成后供甲方使用，这个系统的TPS是多少？硬件配置/用户矩阵是什么？系统可靠性4个9还是2个9？你可能会说，我们的客户要求根本没有这么严格，能用就行，实则不然，如果说一年没问题，一年后客户的用户数量增长了一倍，忽然发现系统卡顿，几乎不能使用，客户找你算账，这该怎么办？谁的原因造成的..... 你说我们给自己公司做的产品，不要求这些东西，满足当前用户即可，那我现在问你，你的系统用户承载量是什么？当你真的出现用户数量激增，你该如何应对？
- 框架标准化，如果一个企业中多个项目使用的框架五花八门，真正出现性能问题的时候，只能大家齐上阵，见招拆招，忙的不亦乐乎，其实收效甚微。
- 翻译需求，很多功能逻辑说不通，但又没法改，为什么？客户要求如此、产品经理设计如此，产品经理也已经不在了，原型设计文档找不到了，当然这种项目都是比较老的项目，很多公司都会存在此类问题。
- 灰度发布系统，深夜一群人呆在一起发布一个系统，一起处理bug真的是团队团结的表现吗?回家陪陪老婆孩子，好好休息，第二天的工作效率不是更高吗？
如果现在让我做一个系统，我应该如何设计？趁着周六有时间就这四个问题简单聊聊，希望能够对大家的工作有所启发。
系统参数
你打开的汽车使用说明书，它会告诉你它在什么温度下可以正常工作、最高时速是多少、承客量多大......如果出现问题，仪表盘会给出什么样提示，你应该如何规避这些故障。软件系统也一样，你的安装部署手册里要告诉别人你的系统需要多大内存、多少硬盘、什么规格的CPU来支撑多少用户量。设计文档的非功能性指标应该包含系统每秒处理事务数量（TPS）或查询数量是多少、安全性指标等级甚至支持用户数量；你的管理端界面或者监控系统应该告诉运维人员CPU占用量、内存占用量、硬盘使用情况、带宽使用；阈值告警参数，触发阈值产生告警，研发人员如何查看日志排除故障。
说的简单，这些指标从哪里得到呢？没有特别好的办法，只能通过压力测试、稳定性测试、安全性测试甚至平时的故障模拟中得到。
确实这些度量指标非常昂贵，甚至要超过你系统本身的成本，即便如此，你要去做，因为你不去量化一个系统，你就无法管理一个系统，可以想象一下你每天都是在闭着眼睛开车，你永远不知道您离灾难有多近。所以你要说服你的老板，抵挡住节省金钱的诱惑，认真对待系统指标数据。
当然完全做出这些东西到底有多复杂？我作为过来人认为并不复杂，而且能减轻不少后期工作量，想想一个系统不会所有的接口都对性能有要求，所以你只要评估出存在性能瓶颈的接口加以性能测试即可；另外性能测试脚本开发完成后都是复用的状态，所以不会产生太大工作量，而且又保证了每次上线之前都可以自动化验证部分接口，这不比人肉点点点香的多吗？
另外像一些系统层面的参数指标，比如Http调用成功/失败情况、CPU、内存占用情况、告警等，可以搭建一套监控工具，比如Prometheus等。完成此类指标的获取。
如果说我的系统总共就几个人用、或者这种付出和收益完全成反比，那当我没说。
框架标准化
框架，通俗来说也就是我们产品/项目架构，就架构本身而言，一定先有设计目标，架构要去干什么样的事情，去完成一个购物网站还是一个管理平台，存在很大区别；根据设计目标，应该定义出设计原则，这也就是平时经常见到的控制反转、里氏替换、最小依赖、单一职责等原则，加上清晰的边界和实现价值（架构做什么，不做什么）；最后通过使用Gof总结出来23种设计模式加上算法就形成了一套框架。在这个框架的基础上就可以开发我们的应用。你可能会反驳我们项目五花八门，经常变动，一般架构很难满足，甚至架构需要经常改动，大概率是框架抽象定义的不够好，你看看你平时用到的tomcat框架、spring框架，你感知到它的存在了吗？反而像早期IBM做的weblogic、jboss什么都做的重量级框架，已被抛弃，所以解耦和抽象再怎么强调都不为过。
定义好框架只是第一步，下面就是使用了，就目前国内情况而言，开源项目越来越火爆，所以基本上从网上找找，七拼八凑就行成了一套自己的框架，这本身而言也没有错误，极大降低企业框架定义的成本，但是一个框架通常只能解决某一类的问题，所以前期就需要架构人员进行反复编写代码进行测试和使用，得到这个框架自身的数据，而不是看见别人用的很好，别人多少数据量都可以轻易支撑起来，别人的使用场景很可能跟你不一样，要不然为啥市面充斥着五花八门的框架，大多数原因都不能从根本上解决自己的痛点问题。
接着架构人员要参与到编码中，发现问题及时更正和修改，引导开发人员如何划分模块，关键时刻做出示例，进而形成自己的开发规范，而不仅仅是站在一个指导者的角色，口头告诉程序员该如何使用，满足不了性能指标或者业务一团糟的时候开始考虑拆分，然后拆成几个微服务也是乱上加乱，根本不能从本质上解决问题。
总结来说，做架构首先要考虑的是自己的需求、目的及边界、原则、实现价值，最后才考虑技术实现和工具组件，而不是首先撸出一套框架生搬硬套，最后说程序员不会使用，代码写的太垃圾。
翻译需求
通常来说，一般是提出需求，架构人员进行架构设计，产品经理画出原型设计，开发人员开始设计、开发、提交测试交付。最后一个阶段看似已经定型，按照需求完成任务即可。但是人都会犯错，作为开发/测试人员不能对照原型、设计文档翻译需求，出现问题后，自豪的说，就是这样设计的，我也没办法，你找产品去。但是你有没有考虑过，即使产品人员改了改需求，最后你不还是照做，受伤的还是自己。所以我们在做任何一个功能的时候都要搞清楚问题的本质，事情的初衷。
你可能会反驳说，我的产品比较强势，他做的东西面向的是用户，开发人员是无法理解的，照着做就行了。但我觉着这些并不是理由，如果一个产品说用户要求的，你可以站在一个用户的角度去理解，如果是从数据角度，让他把数据拿出来，如果讲不明白，你完全可以拒绝，否则你做出来的东西肯定是四不像。所谓铁打的营盘，流水的兵，换了几波人之后完全无法理解这种逻辑，产品如何迭代。你要说你的产品功能过于复杂，大多数是产品设计就存在一定问题，你看看你常用的应用，那个不是简单易用。
为什么要对开发人员强调需求呢？因为你的需求做的不严谨，存在漏洞，都会给后期的性能、再次开发埋下祸根，而且这种问题，越往后解决成本越高。
灰度发布
相信大家面试的时候经常会听到面试官问这个问题, 如何保证一个系统高可用？如何做到不停机发布系统？答案也很简单，负载均衡，当然负载均衡也有很多种，有基于域名重定向、DNS、IP、数据链路层的负载均衡，你可以根据你服务自身情况，选择一种适合自己的。当然你会反驳我说，我的系统就一个副本，不要求高可用，那我会说，你敢白天上线吗？如果不敢，请乖乖做灰度发布（金丝雀、A/B、蓝绿等等）。
这并不是凭空增加大家的工作量，不知道大家认不认这样一个事实，软件发布通常遵循墨菲定律，往往不好的，一般情况下不会出现的问题，甚至没有想到的，都会在线上出现。要么人家都说运维人员都相信玄学，其实倒不是因为玄学，是因为存在未知。线上的用户、历史数据量往往最多的，也是最全面的，所以线上更容易复现一些问题。通过灰度发布部署多套，开发/测试人员完全可以在工作时间、站在用户的角度测试完成后上线发布。否则直接回退，即实现了测试，也没有影响用户使用。
灰度发布说简单也简单，最简单的你在你的nginx写几句lua脚本，便可以把包含特定标识的用户路由到特定服务。
总结
看完本文后，感觉会有点诧异，说的不是性能优化吗？不应该讲讲连接池配置多大、缓存如何使用、系统优化、硬件配置、甚至代码如何编写的一些技巧吗？怎么扯了一堆没用的。从某种程度上来说，软件的性能优化成本往往跟前期的软件设计成本反比，前期在设计上花费的时间越多，往往后期优化成本就越低。没有任何组织能够一开始就做一个高性能的软件系统，大多数都是随着用户和数据的增多演化而来。前期的性能指标、系统架构、甚至功能需求编写都能够为后期软件性能优化带来帮助。
