太棒了，醍醐灌顶，这操作系统和应用开发融会贯通，太棒了。 老师，遇见你是我的幸运。

存储这里确实水比较深，这篇专栏还只讲了关于数据库存储的部分，文件存储似乎没怎么涉及，只有在最后的 Apache Cassandra 部分讲了一点。 另外在数据库备份里面，似乎也跳过了主备数据库机制（由于浪费了服务器资源，似乎已经不怎么使用了）。 专栏中的数据库分片似乎是把分库和分表也合在一起讲了，不过这个部分本来也是需要专业的 DBA 来设计吧，架构师只能提出个框架而已。 NoSQL 的另一个说法是 Not only SQL，应该是作为传统关系型数据库的一个补充吧（用于存储文件或者对象），估计还没有哪个系统可以抛弃关系型数据的。 列式数据库似乎也没有提及。 关于思考题，分布式存储架构的动态伸缩，我只能按照前面的思路，想到一致性哈希算法，而留言里面 @Victor 大神的留言非常全面，不再重复。

我感觉类图不太实用，如果能够画出类图来，那么基本上代码也就写的差不多了。而且可能会遇到代码已经修改，但是设计文档中的类图已经过时的问题。好像也够工具可以直接从代码生成类图，以前 Visual Studio 就可以生成类图。 部署图估计是每一分架构设计里面都会有的，不过专栏里面画了两个立方体有点奇怪，我之前看到的至少会把数据库画成圆柱体。 用例图是我认为最有用的，特别是在需求分析，以及概要设计阶段。做一个项目，不论大小，至少应该先有一个用例图吧。 在我看来，序列图和状态图只有在遇到比较复杂的情况下，对于沟通或者整理思路很有用。但是如果用 Visio 或者其他工具可能会比较复杂，把时间都花在做图上，如果有可能，我倾向于手工或者白板画图，比较简单，并且利于修改。当然如果最后形成正式文档的时候，也可以花一些时间，美化一下。 UML 中没有流程图，但是有活动图，在我看来，活动图有点像“立体”的流程图。 估计最终在架构设计文档中还是会有流程图的，否则感觉缺了点什么。 之前的项目，在架构设计文档里面，为了撑门面，一般都会尽可能多的画图；在方案评审的时候，评委很多时候也会对图比较重视。但是也有一些项目，是先撸代码搞起来，在最后评审的时候才去补各种设计图。 如果让我来做架构师，那么用例图（场景）、组件图（逻辑）、部署图（物理）、活动图（过程）应该会有，好像还缺一个开发视图的。

这个专栏对于在程序设计上的指导意义，在我心中是NO.1。

李老师，我感觉这句话是非常对的，“如果你不填老师想要的答案，你就是个傻瓜”，这对中国的现实情况是一个深刻的写照啊，你做一件事情，一定得为“老师”带来价值才是有意义的。干活满满！谢谢李老师！

如何提升自己的技术能力，让自己快速进阶。 1. 勇于承担责任，有机会多做些技术挑战性的工作。 2. 多实战，多思考，多总结。 3. 关注问题场景，基于场景寻找解决方案。

软考考了好多，当时要是学了就好了

从老师的课程开始接触极客时间，老师概讲讲的很好！对我帮助很大！

有的时候似乎重新回到过去，但是却有了本质的区别和进步。👍👍👍

感谢，之前只是知道preparestatement会生成语法树避免的注入，现在才明白是生成执行计划，避免的注入