回顾了架构的变化，如下图：
云化和容器化给开发，部署和架构带来了巨大变化，包括团队的构成，例如DBA是否必要，同时也让DevOps和微服务变得切实可行。
容器化将（1）常态化 - 尤其是当ISV也把它们的产品容器化后；（2）促进分布式架构在传统企业IT里的采用（此前，大部分垂直行业IT并不擅长互联网企业所擅长的分布式架构，现在只要接受了容器的概念，显然就走向分布式）；（3）促进已经讲了8年以上的DevOps落地可操作。
SOA和微服务的不同，采用微服务架构要考量的方方面面，去IOE实质是去中心化和传统的架构方式，企业要修炼的是内功包括架构，体制和文化，倡导学习型组织和工程师文化，让技术和团队保持持续的进步和革新。
构建DevOps产品的经验总结。
错误1：概念耦合。最典型的就是没有将DevOps、CaaS、MicroService拆分开来看。
错误2：关键设计未集中来做。最典型的问题就是数据模型（ER）的设计下放到每个子系统去设计。
错误3：MVP未深思熟虑，未采用最工程化方式来实现。
错误4：没有引入流程引擎作为底层支撑，更何况是我们有流程引擎成熟产品的前提下。
错误5：康威定律的实践问题，异地团队与子系统的结合方式有些欠妥。
错误6：架构师的参与度不足。
相应的调整
组织架构的调整，拆成了独立的三部分来做，分成DevOps团队、容器云团队、微服务团队。
引入EOS（开发平台）、BPS（流程引擎），支撑平台下一个MVP的工程化交付。
概念模型到数据模型的总体设计，将DevOps分为产品管理、项目管理、交付中心、代码&构建、权限管理五部分。
不再自己杜撰需求（当然之前也不是杜撰的，只是与实际结合还不够紧密），结合灯塔客户的具体需求与状况，来辅助完成产品研发。
团队分工，异地做一定牺牲，前期需求与设计阶段在一起办公，同时独立分出架构师，全职参与DevOps产品研发和实施。
NIO
事件驱动模型
避免多线程
单线程处理多任务
非阻塞I/O，I/O读写不再阻塞，而是返回0
基于block的传输，通常比基于流的传输更高效
更高级的IO函数，zero-copy
IO多路复用大大提高了Java网络应用的可伸缩性和实用性
还是得把Java I/O, NIO and NIO.2和Pro Java 7 Nio.2看看。
