本文是阶段性的一些系统性思考开篇杂谈
一、复杂的事情简单做
简单的事情快速做，复杂的事情简单做。在过往经历中，有很多人为了纯粹的技术，做了很多不合理的事情。
案例一：任务补偿。数据量很小，使用定时任务+状态就能快速实现的。结果是一定要引入 mq 等中间件来实现。
案例二：一个简单的同步任务，只需要快速实现功能即可，结果是将功能往平台、往底座去做，杀鸡用牛刀。
案例还有很多，不一一介绍。
越少的代码、越少的依赖，功能就越稳定、也越容易维护。每多一行代码就多一分出错的可能，每多引入一个中间件，就多一种隐患。
不是说不能设计高并发、高性能、高可用架构， 恰恰相反，我们需要拥有这样的能力。 最重要能在众多方案中选择最适合、最经济、最可靠的那套。
矛盾点: 技术不标新立异，在晋升的时候可能没亮点！ （过去遇到过的一些尴尬局面！）
想得多一点、做得少一点
前段时间考虑做一个短链服务。如果只是简单做，可能就是一个 map 映射。
但是，我们需要考虑的点其实挺多。
- 性能/高可用：缓存、支持的QPS等
- 安全：恶意请求；通过短链code遍历，拿到所有原始链接
- 扩展：支持原始URL的修改；启用停用
- 国外加速：服务部署节点支持多地区
有可能我们并不需要那么大的量，所以这些实现考虑根本没有必要，但是当真正问题出来的时候，我们是有对应策略的。
想得多，做得少。
二、资源评估
资源就是钱！ 合理地使用资源， 避免不必要的浪费！
对于资源的综合评估也能从侧面考察技术功底和能力！
在大公司，由于资金雄厚，可能不那么在乎资源的合理使用。 因此也遇到过很多浪费的行为：
- 业务已经停止，应用下线，但使用的机器资源却一直在线。
- ECS数申请过多，每个机器的资源使用率并不高，每台的 cpu、内存等都没有达到 30%。
- redis 申请评估不准，以为 redis 30G 会很小。但根据业务而言，做简单的缓存，已经远远足够。
- 一上来就搞分库分表。申请2个库，分表1024张，最后发现总数量也就几百万。
显然，这些都是非常荒谬的事情。作为架构师、技术经理，合理地评估资源的用量是非常重要！
这是一个综合值，有参考依据，当然很难做到精准，但绝对不能离谱。
由于现在很多中间件、数据库等都支持弹性扩容， 所以先闭环再根据业务的发展对资源进行扩容处理。
但在架构设计和实现上，则要考虑资源扩容带来的影响，比如是否兼容从单表改成多表！
三、设计思想
绝大多数问题，都有相应的解决方案，它是行业的经验，同时也能给新问题起到启示。
3.1 大拆小思想
将大拆分成小思想。任何棘手的问题，都是可以拆分成小问题。（或者说分治思想，将大的问题拆分成一个个小的问题）
案例一：比如12306火车票，不可否认，12306的总并发数很大，但是分摊到每一个车次 QPS 就会小很多。
案例二：库存扣减问题，如果我们将库存数量，拆分成多组。因此资源的争夺就从1分变成多分。
分布式锁从1把变成多把，显然性能也能得到提升。
另外再举一个例子。 ConcurentHashMap1.7 的实现。采用了分段锁机制，把 Hashtable 的一般锁换成了 Segment分段锁。
显然这是一种提升。
3.2 小步快跑思想
先完成再完美；快速 MVP，快速迭代，快速试错。
四、方案能力
针对业务场景，选择合适的技术。
案例一：使用关系型数据库实现一套 feed 流是比较费力的；而现在用 TableStore(表格存储) 则表达容易。
案例二：用关系型数据库在海量数据面前搞搜索是一件很痛苦的事情，但用了搜索引擎就变得轻而易举。
新技术，会让一些过去实现复杂的场景的简单。新技术的出现会解决很多复杂问题。
技术的广度和技术的深度，两者结合，称为方案能力。
五、用图展示思维
有一些图是深刻的，是有动态效果的。但决定不是简单的豆腐块拼图。是有逻辑内涵在里面的。
本文到此结束，下期再见。
