今天跟大家分享的标题叫
《收获不止Oracle》三年前我在一家书店“纳凉”时发现了一本书《收获不止Oracle》今天抛开Oracle不谈，我们来聊聊这本书是怎么“收获不止Oracle”的
《收获不止Oracle》这本书中讨论的是Oracle数据库调优的问题，到底是什么东西能让人们在本书中的收获不止Oracle的？这个问题要从如何解决Oracle性能瓶颈的问题来入手。
书中解决Oracle性能瓶颈的问题遵循的唯一原则就是少做事儿！ 作者肯定的说，少做事儿，就一定能提高效率！道理很简单，举个例子来说~
-
一个流程，原来需要走6步才能完成，现在在不增加额外负担的情况下把它优化成只需要5步，那效率就一定提高了！
-
拿算法来说，也可以简单的理解为根据具体情况，找到让CPU运算次数尽可能少的得到结果的办法
少做事儿的思想可以应用到各行各业，当然不局限于Oracle。
如今大火的运维自动化、DevOps、CMDB等概念都是少做事儿的最佳体现！但是这三者有一个共同点！出发点都是让人少做事儿，将人工的重复劳动加以归类整合，让机器自己去完成，从而实现了通过少做事儿来提高工作效率。但以上这些理念并没有触及到业务的核心问题！就是业务上是否存在不必要的冗余！
上面提到的技术，解决了让人少做事儿提高效率的办法，那第二个层次就是让机器也少做事儿，就能再一次掀起技术革命，提高运行效率！让机器少做事儿，也可以归到以下两个层面
-
代码：让单台机器上的代码少做事儿（减少代码级别的冗余）
-
流程：精简业务集群的工作流程（减少不必要的流程和交互）
针对上面提到的代码级别的少做事儿实践中，最常见的就是优化业务逻辑和算法，比如购物平台的商品推荐算法、搜索引擎里推送广告的算法等等；还有一种情况是干了重复的事情，需要精简
针对流程级别的少做事儿实践中，最常见的优化方法是调整技术架构，精简不必要的流程和业务环节。例如：数据库很慢，就不要让数据库干那么多活，在数据层之上加入中间件就是让数据库少干活的经典体现。再例如：业务逻辑方面，可以让用户一步操作就完成的事儿，就不要弄得那么繁琐。
以上是基于少做事儿的个人理解。提到今天分享的内容，我想起刘龙军“前辈”关于“微服务”理念的那次分享，微服务其中解决的问题之一就是冗余问题，我觉得我们可以把微服务理念理解成面向对象编程里的封装这个概念！面向对象的终极目标是减少重复代码，实际也是少做事儿的一种体现。所以微服务当今大行其道是大势所趋。
最后和大家分享两个我个人关于少做事儿的实践案例
背景：我上家公司的日志处理流程，每天凌晨脚本在client端收集昨天的日志，处理后打包上传到分汇总，分汇总拿到所有数据后对数据进行处理后上传到汇总，汇总对数据处理后将源数据打包上传到备份服务器。大致流程： client-->分汇总-->汇总-->备份
-
少做事儿代码级别的体现：在client端，服务器以及应用的一些参数经常变化，导致脚本经常因为各种情况而崩溃。经过长时间的考察，我决定比较激进的将client端的环境变量根据更新频率的不同分为三个等级，每个等级的变量的刷新都有自己对应的方式，实现了少做事儿的理念
-
变量被分级，每天脚本自动刷新的变量只有获取IP和时间（之前是每天都刷新所有的环境变量），减少因为人工误操作信息表，而读取到错误的应用配置信息
-
得益于变量刷新分级制，原来脚本中对于各种各样意外情况的try代码块可以完全剔除
-
少做事儿流程级别的体现：原日志备份从client端到备份服务器，需要经过分汇总和汇总两道关卡。熟悉业务流程并保证日志有足够多的冗余备份后，剔除掉了汇总这一层的备份流程。由： client-->分汇总-->汇总-->备份 简化为： client-->分汇总&备份-->汇总
- 分汇总拿到源数据包后直接将上传到备份服务器，不再经过汇总服务器，减少了一个流程，效率就一定有提高！
上面举的两个实际案例都是少做事儿的非常简单的应用，希望抛砖引玉，可以给大家一点启发~~~
网友评论