2019年05月09日之有所思

这是群里一位前辈兼领导，跟我们的分享:

我来随便举一个我以前的例子，来写一步步的分析过程吧.
示例：一个获得订单详细信息的接口. 如果对订单不是很熟悉的话，你可以把这个想象你的一个京东订单详情页面，有订单的基本信息，订单的详情（商品A,商品B,…等），订单的状态，进度等.

我们假设这是产品同事的一个需求，我先说下我们一般的程序员怎么来处理。
前端：“我需要一个接口来获得订单详情”
开发：“好，我写一个，一次性来给你返回.还简单！！”
前端：“谢谢”

但是当业务量增大的情况下，这个接口会显比较慢，甚至崩掉。然后我们有了如下的措施

“上负载吧。多台负载机. ” 这当然能解决问题。很显然，这需要成本
“换数据库吧？”，这也能在一定程度上解决问题，这也需要成本
“这个EF不行，换Dapper吧”…也许会有一定提升.(我认为EF也许效率是不如纯SQL,但是绝对不至于有那么差，要不然微软推了10多年)。
“退了吧？重做吧？”
…等等

以上措施都是有用的，而且有一些都非常有用，但是是否还有其他途径以及分析手段呢？肯定是有的，我接下来从数据的变化性以及数据的时效性来分析下.

数据的变化性，顾名思义就是数据是否变化，对于上面我说的这个例子，一个订单的详情是否变化？一个订单的数据有很多，我想说的是99%不会改变。你可以想想自己的京东订单？除了发货状态，物流状态改变？其他的变过吗？
数据的变化频率，对于订单中唯一变化的发货状态，物流状态 ，他们的变化频率是时时刻刻都在变化，还是半个小时变一次？还是半天变一次？
数据的时效性，对于变化的数据，消费者晚几分钟知道，是不是可能会造成一定影响？是有影响还是没有影响？如果有影响的话，客户是否可以接受？对于我个人来说，我晚10分钟知道我的订单的状态改变没有任何影响，甚至1个小时对于我来说都没问题。：）
数据的查看频率，我是京东的忠实用户，但是对于已经完成的订单，我从来不看。：）

通过以上4点的分析，我们可以将接口分成2个
获得订单的基本信息，也就是从来不变得信息
获得订单的状态信息，也就是变化的数据.

说到这里，很多小伙伴肯定要说了，你的意思就是要用缓存吧？对，我就是说的是缓存，但是怎么用？怎么把影响范围做到最小，还是需要分析的。

问题1：前端同事会说，你们开发说的简单，你们改改，我们所有用到的地方都要改成2个来说获取。
解决办法：为什么要有网关？为什么不让前端同事直接调用api？网关不仅仅就是个二道贩子，对于把以前接口一分二或者更多的改变，网关提供了聚合功能，也就是说虽然API分成了多个，但是我们可以在网关上，把数据重新组合。前端根本就不会觉察。

问题2：缓存，我要把需要缓存的地方，都需要加上先查看Redis中是否命中，然后没有的话，再从数据库查，然后再保存，虽然这个功能很简单，但是也要改动，改动还不小
解决办法：
首先我说上面的基本思路是一样的，但是上面这个重复性工作太强了，要是我，我就不会这样做，我会在API的上面加一个CacheHeader(如果您连Header都不知道的话，不会写的话，那我建议你去学习.NET基本知识)，也就是说所有添加CacheHeader的API都会进行缓存. CacheHeader对结合传入的参数来进行缓存.

问题3：缓存时间的控制
解决办法：我会进一步扩展上面的CacheHeader，添加一个时间属性。

伪代码如下：
[Cache(Day=10)]
public BasicInfo GetOrderBasic(string OrderId)

如果参数是00001， 也就是说订单00001的订单信息会缓存10天，10天后，谁还会看你的订单？：）
如果参数是00002来查询的话，没有缓存的话，它会去执行目前的真实操作.

[Cache(Min=10)]
public OrderStatus GetOrderStatus(string OrderId)
也就是说当查询某个订单的状态时候，会缓存10分钟…

是不是改动很小？很简单？

通过以上的措施，就是，当你在京东买了你最喜欢的苹果手机的时候，我能想到你的心情，恨不得立即到手，恨不得一分钟一刷，然后一个小时刷了100次：），你给我们服务器增加了多大的负担，真讨厌：）。但是对于我们的程序来说，您第一次查询订单基本信息是个真实查询，从后面99次都是从缓存读取的。关于订单状态，实际上仅仅查询了6次…我们欺骗了你.：）

其实关于这个页面还有很多思考，我就不写了

最后我想说的是，我从来不怀疑大家的开发能力，但是怎么思考，怎么提高？这和岗位，职位,经验都没有太直接的关系…

实际上，我匆匆看完后，就觉得，对于我来说，是一种食之无味弃之可惜的分享。案例只是一个皮儿，它可以是一个随意的什么案例，前辈要表达的思想，和想给新人传递的思路很显而易见。
但是我却有了更多的思考。原本潜藏的很多想法，以此为突破口涌了上来，并借此开始有所组织措辞。
下面是我的回复：

我的临时个人总结：
外在体现主要是：
1，合理的拆分接口，会主要体现在合理的调用频率上，合适的响应速度上
2，合理的使用硬件资源，从客户端到网关，各种中间件，到服务器，到数据库，负载良好，抗压能力良好
3，再细致一点的就是良好的用户体验和前后端之间的交互上

我自己的现在的理解是：主要体现在后端开发对于数据的提炼与掌控上面，前端对用户行为的掌控上。本质就是数据流的良好循环。
如有的数据会频繁读取但很少更新，有的数据频繁更新但很少被读取，有的数据既频繁更新又频繁读取，有的数据需要永久保存，有的数据仅仅即时推算并使用。如何把它们放在更合适的硬件资源上，减轻硬件压力并提高并发或流畅性。

前端能做好多少一方面依赖自己的交互技巧一方面依赖后端如何更好的提供数据；后端如何能更好更快的提供数据一方面是逻辑本身另一方面依赖合理的数据库表间结构；关系型数据库的表结构，一方面是数据关系提炼一方面是对需求的理解和发展方向的预推测。每个环节都是既依赖自己又依赖他人。

当然了，纯前端架构或纯后端架构或纯数据处理就另说了，这些本就很少掺杂业务。

我觉得这些是我们所追求的，尽管几乎没有尽善尽美的代码。就像时间没有尽头但我们仍需前行一样。

我说的东西都比较宽泛，毕竟总结性的，但实际上每一点都有很多实际案例，这需要我们自己去丰富自己的经验阅历技巧等去填充。

呼，爪机敲得好累

是的，我是在手机上回复的，一口气敲出来的。所以我才想这些想法应该早就潜藏在我心里，只是一直没有合适的机会组织起来。
在敲篇文章时，我忍不住又在想一个问题：如何解释‘关键’，和‘重要’。它俩之间的区别
什么是关键，抛砖引玉之砖，就是关键，这块砖可能一文不值，它也可以是随便哪一块砖，但是，就是需要先抛砖这一步骤，才可能引玉，这就叫关键。
什么是重要，比如一大堆黄金静静的躺在无人知的角落。它对于需要这批黄金去做事业的人来说，很重要，但并不是关键事务，关键点在于什么人知道它在哪儿，最终会被谁得到，黄金本身不是关键，关键是谁拥有它。这时的黄金，就是很重要。
当然这是一种比较狭义和主管思维上的区分，广义上，和单语意上他俩甚至可以互换互用。我只是以个人思维，从节点和流程的角度上去‘较真’一下。