编者按：微服务在带来良好的设计和架构理念的同时，也带来了服务运行和管理上的额外复杂性。在基于容器的微服务架构中，由于服务运行的位置、数量和时间的不确定性，传统用于虚拟机的性能监控和日志收集方式很难适应容器应用动态变化的特点，那么如何通过现有的开源工具对集群中的容器进行监控和日志管理呢？5月7日下午，Thoughtworks资深咨询师林帆在成都举办的“架构师实践日”沙龙上，为大家带来了相应的方法和实践。以下是对他演讲内容的整理。
林帆
ThoughtWorks高级咨询师
专注DevOps技术领域，长期从事于软件开发运维以及社区宣传工作，在容器技术方面有十分丰富的实践经验。热衷于对DevOps和容器技术应用的推广，在CSDN、InfoQ和《程序员》等媒体和杂志上有许多相关领域文章，著有《CoreOS实践之路》一书。
SOA与微服务
图1是一个比较典型的单体应用、SOA应用和微服务应用的示意图。
▲ 图1
SOA应用是强调将服务根据业务的关联性进行解耦合拆分，而微服务则是在解耦合基础上，更强调让每一个服务之间可以自己独立开发、独立部署、独立运维，并且每一个服务使用适合各自领域的技术栈，有各自独立服务的团队，发挥各领域的特长，所以微服务并不是与SOA对立的一个观念。微服务每一个服务的部署频率可能会很高，并且每一个服务的计算量不太一样，这样就可以通过适合某一个具体业务的技术栈或者具体框架，分别实现每个部分，然后把它们组合起来。
微服务的复杂性
微服务相对于单体应用，在灵活性、可扩展性上要高很多，但是它的高灵活性是有一定代价的，这个代价主要在它的复杂性上。
微服务的复杂性体现在多个方面，首先从软件管理上来说，要管理一个微服务架构的产品，比管理一个单体应用产品要复杂得多，因为你需要管理很大的一个团队，并且每个团队有着不同的架构。对此，很多时候我们需要让开发者有自主的管理权，让他们可以自己做运维做部署。除此之外，对于服务调试来说，微服务的调试也比单体调试复杂得多，一旦一个产品线上出现问题，就需要开发团队更好更默契地去协调团队与团队之间服务的划分和调试。
另一个微服务的复杂性，还体现在微服务的基础设施上。以前单体应用升级服务的时候，平台可以决定什么时候能部署，但是对于SOA甚至微服务的架构来说，从平台来看，它所认为的每一个服务的部署基本上是无序的，它无法预测一个服务在什么时候被部署、部署几个、需要多少资源等等，所以平台就要做监控，就会限制自主开发权限，这样就会使得对整个服务架构管理、控制以及维护的成本比普通级应用高很多。
在基础设施的构建上，一般来说只要涉及到微服务的架构，基本都离不开分布式的结构。而基础设施的设计必须要适应服务架构，因此基础设施也必须按照分布式的方法去设计，包括需要考虑如何去做自动化的分布式部署，如何在不确定的环境里去完成故障的定位、故障的管理以及服务状态监控。
我们现在经常提到的容器、Docker化，为什么经常会和微服务放在一起呢？很大程度上是因为服务的部署和服务运维的复杂性，而通过容器我们可以为各种各样不同的产品和服务，做统一化的部署流程，这对于我们整个微服务的规模化的生产就提供了可能性。容器的使用带来了一定的运维上的便利性，但也使得很多过去我们在虚拟机上的经验变得不太适用，比较典型的就是服务的监控和告警，比如我们要监控一个容器运行，可能就与监控虚拟机的运行方式不太一样，又比如搜集容器服务日志的方式与搜集虚拟机里面的也不太一样。一方面是因为微服务结构的影响，另一方面也是Docker本身的打包方式带来的差异性，使得基础设施需要进行一定的变化。
服务的监控和告警
从功能上来说，服务的监控可以分为两种类型，一种叫做黑盒监控，另一种是白盒监控。黑盒监控，它是指在不知道服务具体运行的情况下去检查这个服务本身是否可用，以及在它出了故障以后如何进行故障的恢复。这种监控方式在容器和非容器上差异性比较小，但是与具体使用的技术栈或者是平台会有比较大的关联性。白盒监控是指我们需要去了解这个服务器内部的运行状态，比如CPU使用率是否爆满，磁盘占用一段时间是否出现异常。白盒监控的主要作用有两点，一种是出现严重故障的时候，我们要对发生故障的现场进行回溯，另一种是我们通过监控数据能够去预测一些可能发生的问题。
目前，大部分基础框架或者平台本身是不做白盒监控的，通常来说是由我们自己搭建，或者使用SaaS服务，比如Datalog、OneAPM、Sysdig这3种，都是SaaS服务中对容器化的场景兼容比较好的。对于这种SaaS的解决方案，一般来说结构分为两层，一层是数据收集端，不需要部署在每一个容器里面，甚至不需要在容器里面做数据收集；另一层是SaaS端，SaaS端会完成存储、展示、告警以及后续的一些服务。对于一些不想自己做运维或者是想比较快速的搭建一个监控产品的用户来说， SaaS的监控方式会比较适合。
当业务规模还比较小的时候，SaaS这种按需购买的方式可能比较划算，但是当业务达到一定规模，按需购买可能就不如运维人员自行开发了。
cAdvisor/CollectD/StatsD
InfluxDB/OpenTSDB/ATSD
Grafana/Graphite
Zabbix/Nagios/OpenFalcon
Hawkular/Prometheus/Riemann
…
上面列的是一些比较常见的开源性能监控解决方案，但并不是每一种都适合容器化的产品，比如Nagios和Zabbix就不适合。比较推荐的几个监控方案是Promethus和Influxdb，这两个属于数据层的服务，最上面还有数据展示层的服务。当我们自己搭建一个监控的时候，需要考虑的东西会比使用SaaS服务要多很多，除了用多个开源工具去组合，开源的软件里面还有一些整体的解决方案，比如开发平台。
日志收集
传统的日志收集方案有Splunk、Logstash、Flume、Fluentd等，其中Splunk和Fluentd被列入了Docker官方文档里。Fluentd是一个出来时间不长，但是对传统收集工具 Logstash挑战比较大的收集方案，同时它也在去年被亚马逊评为最好的日志收集工具。Splunk则是一套基于商业的解决方案，一般只有大型企业才会使用，这种方案是目前最好的，但也是最昂贵的。
在其他方案中，传统的解决方案最常见的是Logstash，它的配合工具一般是Elasticsearch和Kibana。图2是一张经典的ELK架构图，首先在每一个节点上部署一个Logstash数据端，称为shipper，然后搭一个redis的缓存，在redis缓存后面再用另一个Logstash去做索引，称为indexer。之所以有这样一个架构是因为Logstash本身运行效率率比较低，用的是JRuby语言，它使得索引不能在每一个客户端去做，因为会占用很大的的内存。
▲ 图2
Fluentd的方案与Logstash差不多，但是它可以省掉Indexer这层，而且它的核心代码是C++写的，从效率上说会比Logstash高很多。除此之外，Fluentd是除了Splunk以外唯一一个在Docker官方日志驱动里面的工具。一般来说,日志收集是通过收集文件的方式进行的，因为Docker会默认将容器的日志放到一个指定的目录里。Logstash会去搜集目录里面的日志，但是存在一个问题，就是Logstash在搜集的时候是每隔一定的时间在目录里面做一次查询，这样很可能因为监测的服务出故障造成日志丢失。Fluentd则不仅支持Logstash那种文件的方式去搜集日志，还可以通过Docker的Fluentd driver直接定向搜集，但是搜集的日志Docker log命令是看不到的。对用户而言，可以根据实际的应用产品，对这两种方式进行选择。
获取架构师实践日第七期视频回放链接，请在七牛云公众号后台回复关键词：71
「七牛架构师实践日」——这里只谈架构
七牛架构师实践日是由七牛云发起的线下技术沙龙活动，联合业内资深技术大牛以及各大巨头公司和创业品牌的优秀架构师，致力于为业内开发者、架构师和决策者提供最前沿、最有深度的技术交流平台，帮助大家知悉技术动态，学习经验成果。
标签： 客户端状态监控