对于架构师来说，如何把握预测的程度和提升预测结果的准确性，是一件很复杂的事情，而且没有通用的标准可以简单套用，更多的是靠自己的经验、直觉，所以架构评审时，经常会出现两个设计师对某个判断争的面红耳赤的情况，原因在于没有明确标准，不同的人理解和判断有偏差，而最终又只能选择一个判断。
关于(2)，为了应对变化，通常将变化封装起来。
常见的方案有这么几个?
a.将“变化”封装在一个变化层，将不变封装在一个独立的稳定层;
b.提炼出一个抽象层和一个实现层;
关于a,可以用一句话来概括“不同的人办理不同的事情”，比如在社会生活中有形形色色的人，有的人善于阿谀奉承，有的人踏踏实实，阿谀奉承的人总有一天会因为某些事情而做了嫁衣，而踏踏实实的人却不受到半点影响，这个社会需要实干家。在写代码中可以反映出，一个函数只办一件事情，变化层应对那些时常变化的，稳定层就待在它的稳定层，这样也解耦，不会有影响变化层有问题而还要改稳定层，不会因为稳定层有问题而改变化层。
关于b,对于抽象层和实现层，对于Java开发很常见，比如接口和实现类就是一个很好的体现。
来自李运华先生的思考题:
你在具体代码中使用过哪些可扩展的技术?最终的效果如何?
针对这个问题，我对此的回答是：
可扩展的技术倒没有使用太多，主要是从代码上扩展，比如从简单方面做起，每次Controller都要打印对应的日志，我让AbstractController继承log4j日志，这样每次Controller需要打印日志不用每次在类里面声明一下。还有就是将Controller代码简化，比如之前Controller太过繁杂，以至于业务逻辑全面在Controller里面，其实最好还是在service中将其写清楚，Controller方面能简化则简化。当然了，还有就是统一代码规范，这里我参考了《阿里巴巴的Java开发手册》，同时也自定义一些特定组件。
最终的效果是，代码耦合性降低，代码的可读性提高，可扩展性提高很多。效果虽然没有达到我预想的那样，但是已经进步了不少。这也是一件让人高兴的事情。
小结:
这两天由于合作方的需要编写了大量文档，这篇文章预计应该昨天就发表的，但是还没有写完。今天仍然没有写完，因为还有低成本、安全、规模等三个方面还没有讲到，我准备留到下次再讲，我觉得高可用、高性能、可扩展性等三个方面，大家可以仔细读读，多多思考。一定会有你想不到的收获。