记录一些我平时思考的碎片，主要是关于产品，因为无论是做平台还是什么，最终都是要推出去给别人用的，每人用就缺乏改进的机会，也就没有了价值。此文长期更新。
1、用户的需求可以理为弱需求和强需求，强需求就是一个产品的基本功能，以数据库为力，提供存储能力，不丢数据，高可用，低延时就是强需求，而周边的配套设施比如监控、报警或者某些SQL语句的支持相对来说可以算做弱需求，这部分需求不那么急迫，又或者可以通过业务设计或其它方式弥补。所以说做产品，理解用户的真正诉求，首先完成核心功能是制胜之道，产品设计中的MVP原则，所指的应该也是这部分。
2、一定要简单，简单的东西才易扩展、可维护。任何一门复杂的学问，它最原始的道理一定是简单的，即便复杂如经济学也构建在简单的供需关系理论上，思考程序设计中的方法也是类似，谷歌的三大论文之所以有效，就是因为它把复杂的文件准确地抽象成了一个简单的模型，再比如并发场景下的akka，基本的模型也是很简单，但是它可扩展，易维护，解决了分布式场景下的高并发问题。
简单可以演绎出复杂，简单的元素可以通过变换、组合演绎出复杂的系统，好像类似于一生二，二生三，三生万物那种理论，哈哈，我不懂哲学，不知道这种比喻对不对。
3、计算机科学是模块化和层次化的结果，任何一个框架，系统都可以拆解为不同组件的组合或者不同层次的叠加。比如hbase包括了master和regionserver两大角色，再细分，regionserver又可以有region/store/memstore等概念，又比如spring是一套java开发中常常用到的框架，其也可以看做是spinrg-core/spring-mvc/spring-jdbc等等不同组件的组合。
4、no-free-launch理论
该定理是由Wolpert和Macready于95年提出，他们证明了对于任何算法或优化算法A与B，如果在某一损失函数上A好于B，则一定存在另一损失函数保证B好于A。换句话说，它指出了不存在可以在任何情况下都优于其它算法的某种通用算法，这就需要使用者对问题的边界有清晰的认识。问题的边界包含了很多层的意义，在机器学习算法中，它可以指代对数据分布的假设，在架构设计中，可以指代业务场景，在大数据系统，它可以指代数据的产出形式和应用环境等等。
5、产品思维和技术思维是两个思维
技术和产品还是两套不同的思维，如果是纯技术而不注重产品，往往成型的作品会离用户越来越远，所以即便是如机器学习、大数据这样的geek向的技术，一个从事这方面开发的团队同样需要一个产品经理，能够从用户的角度统筹规划所有的产品设计。
6、trade-off的艺术
计算机科学中到处都是trade-off的艺术，以分布式系统为例，需要在一致性、可用性和分区容错性三者之间权衡。在GC中，需要在GC吞吐量、GC暂停时间和资源消耗等因素之间权衡，比如即时服务的系统对暂停时间要求高，就需要GC能够与正常服务并行，而某些批量服务，对吞吐量要求高就要求GC释放尽可能多的有效空间。在数据库中，需要在读写速度之间平衡等等等等。
7、防御式编程
不要相信任何人和服务，不要相信下游的话，要最好对自身的保护，没有一个服务能够做到100%的可靠，要做好对下游依赖的熔断；
8、容灾
client-proxy-data server三者之间，不同层次的容灾，要做到首先不同层次之间互不信任，参考上一条防御式编程，发生故障时分层保护，比如高峰期的分层限流等等，最后同一层次的服务之间同级冗余，比如部署多个client端，多个proxy，数据层多个data server。
9、幂等
实现幂等性，可以从接口设计上来避免任何不幂等的操作即可，打个比方，统计用户的like数，当用户点击like时，与其将like数+1，不如在数据库中新增一条用户like了XX的记录，like数由上表统计出来。
10、排查问题方法
查问题的时候先从系统层面去查，看看memory、cpu、io什么的，然后从下游依赖方来查，比如你依赖了hadoop/hbase，看看它们的服务是否稳定，然后排查服务自己。当然这是对已稳定运行了一段时间然后在某段时间出现频发问题这种情况而言。
11、影响系统可扩展的几个因素
影响系统可扩展的因素有很多，根据工作的总结来看，可以包括这些：系统的设计；并发模型的选择，比如是线程还是协程，是基于线程的还是基于事件的；GC的影响，频繁的full GC肯定会影响系统的扩展性；IO，包括网络IO和磁盘IO，当今系统随着网络的快速发展，系统瓶颈已经从网络IO转移到磁盘IO，一个高效的IO模型往往是高性能服务端系统的关键。
12、事情的最开始就要控制好复杂度（包括软件设计、产品设计等等），如果事情的最开始就是复杂的，那就意味将来会围绕着这个复杂的事情产生更多更复杂的事情。
13、设计大型软件时，首先的工作是要把接口定义好。
14、如果不是必要，尽量避免在事务中调用第三方服务。
15、漏斗式分层体系，越往上流量越大，但是处理成本越低，越往下流量越小，处理成本越高，处理结果越精准。
16、大数据系统在上游数据源就要统一掉，保证数据统计口径一致，存储一致，计算一致，避免在下游治理，因为在下游治理起来的代价是很高的。
17、良好的技术素养应该是能够做到对复杂度收放自如，所谓收，是指能够使用清晰易懂的语言描述复杂的技术，能够用简练语言概括出他的关键概念和背景。所谓放，是指能够看到再简单的需求背后也藏着复杂的细节需要抽象治理。做到这一点，就能免于困惑于技术细节而不知所云，也能免于浮于表面而不能落地。