近期做了好长时间的项目，很久没写文档了，这次的项目很难得的自己做了很多的技术方案，且以前有些不一样，现成直接可用方案并没有。 今天闲来总结几点：
1.技术方案大部分从应用场景出来的
技术方案是为了解决一个现成的问题。一个现成的很好的方案，可能在实施成本、冲突方面和项目不符。针对当前的场景也许一个现成的方案可行，但并不一定是最合适的。
2.新的技术方案往往面临需要不断修正
一个全新的方案上替换。在理论上成立之后，一定还有有考虑不全面的地方。尤其是一个已经面对几千万用户的互联网方案,各种各样的客户端环境并不是你所能预见的。在新的方案里，你是否考虑新方案对性能、容灾、稳定性上的影响。完备性上是否有对静态和非静态页面、SEO、对机器人访问、对所有用户浏览器的考虑。只有这些都考虑全了，方案才是真正可行的。而一个方案一开始不一定会完美，需要在过程中不断的面对这些问题并修正。往往理论上很简单的几行代码，会因为这些方面的细节考虑，而变成一个复杂的代码，对代码设计是有要求的。
3.程序的自适应
在设计一个程序的时候，程序的自适应很重要。如配置，要尽量多的基于约定，减少通过代码侵入。同时尽量多的给程序多一些可以配置的入口，约定的文件、编程式的、系统属性、甚至运行期的替换都要考虑。程序要自适应不同的场景，比如生产环境和开发环境，有很多配置的不同，在设计时要考虑对多个场景的自适应。比如要实现一个系统A对系统B的弱依赖，要考虑系统B不可用的时候A怎么自适应，以哪种模式运行，同时还要考虑系统B的接口恢复的时候，A怎么自适应恢复。同时以上情况还要考虑如何自适应区分生产环境的开发环境。
4.多保留一些可扩展的、管控的入口
尤其是对于要在大批量应用实施的通用组件。一定要考虑多一些扩展和管控的入口。也许不同的应用里有些不同的处理情况，所以在可预见范围内要给应用保留一些自己扩展的入口，解决不同的问题。同时由于大批量实施，不能因为一些小的变化就需要所有应用重新升级实施，应该保留一些管控入口，通过运行期可以修改的。比如通过配置一些开关、配置一些阀值，这些开关和阀值在运行期可以动态修改，这样就能很好的对一些通用功能管控。
5.抽象、拆解、并行化
看似一个庞大的系统，当能把它拆解成独立的小模块的时候，小模块角度来看也许并不复杂。拆解的艺术就是把复杂的问题简单化。这和map reduce的拆解有限相似，解决海量数据处理问题，往往看你怎么去把这个庞大的任务拆解成可以独立运行的小任务，这个是解决问题的关键。