最近在思考如果一个人停滞不前可能会是由于什么原因导致，无外乎内外两种因素。「饱暖思淫欲」，满足现状不思进取，没有危机意识，长此以往温水煮青蛙便会自废武功。长期被事无巨细的工作琐事束缚填满，焦虑常伴，让你没有读书、休息和思考的时间，俗话毁掉一个人就让他没有时间去思考。技术领域就是这样，所谓的高薪行业只是被时代选择，没有持续地学习态度，不保持对新技术的敏感度和敬畏之心，迟早是要被后浪拍在沙滩上。
回归架构的工作后有了更多读书和思考的时间，塞翁失马焉知非福。最近一次使用ELK搭建日志系统已三年有余，温故而知新，重新经历了一次踩坑爬坑的过程，有了更多的感悟。
此前搭建ELK的各个组件是基于编译好的二进制包，由于环境差异之前的脚本是不能工作了。考虑到屏蔽差异性，这次除了FileBeat其它组件都选择了利用Docker来搭建，环境变量、网络IP和端口、磁盘映射等是配置时需要重点留意的，稍有不慎就可能导致整个系统无法工作。由于Logstash运行在客户端时会消耗大量的系统资源，占用CPU和内存，目前更优的方案是替换为占用系统资源很少且只负责数据采集的Beat，Beat在发送数据前可能还会进行一些预处理以方便后续处理数据。Logstash部署在服务端，负责所采集数据的聚合和处理，如日志解析和结构化处理等。为了避免采集数据过快来不及处理导致数据丢失，在Beat和Logstash之间通常会利用MQ或Redis加一层缓冲。Logstash处理好的数据最终会存储到Elasticsearch中，Elasticsearch在海量数据、分布式、近实时搜索领域拥有绝对的市场占有率，存储、搜索、分析功能是我们搭建搜索系统时必不可少的功能。Kibana更多的是承担数据可视化的职责，相比传统的ES-Head插件，可以更方便我们去查询和分析日志。在ELK系统的搭建过程中遇到了各种技术细节的问题，如各组件版本要统一、Logstash的grok正则匹配、各个组件对@timestamp时间的处理方式不一致、关闭X-Pack避免对系统间调用的影响、FileBeat的配置项在官方文档和实际不符、Kibana配置的ES地址要使用Docker环境的服务名等，这里就不再一一赘述。
技术只有不断的迭代创新才有更好的生命力，ELK也在不断的进化中发展成为了ELK Stack，不仅只是当初的Elasticsearch、Logstash、Kibana三驾马车，到后来数据采集的Beat，再到安全、报警、监控的X-Pack和云服务的Elastic Cloud，成功的商业化会让开源技术更良性的发展。
架构师属于T型复合人才，首先对于技术的广度有一定了解，要有一定的视野、大局观和技术敏感性，另外在某个领域也要有一定的技术深度，因为很多技术是相通的，触类旁通。架构师的日常工作需要做各种权衡，需要有丰富的经验和一定的方法论支撑。但是不同规模的公司架构师的角色又不能一概而论，大公司可能会细化业务架构、技术架构、系统架构等角色，也许只要把握方向性的东西，小公司可能就是技术TL的角色，也可能事无巨细。
上面这段文字是两年多前我对架构师的理解，大多是从过往经验和他人文字总结得来，是偏务虚的认知，时过境迁，这两年的架构工作让我有了更多偏务实的体会。架构师往往有更多的决定权，所以做选择要更谨慎，选最合适的而不是最好的，强势的架构师更应该避免误人子弟；架构师一定要写代码，指导他人写好的代码是架构师的重要职责，技术人的饭碗不能丢；架构师画图能力很重要，对业务和技术问题进行抽象，最好的表达方式是画图；一定要抽空适当参加技术大会，吸取新的营养，把握技术的当下方向和未来趋势，输入和输出要平衡，虚实结合，既讲方法论，又得脚踏实地。给看到这段文字励志成架构师的更好的你～
