编者按：微服务在带来精良的计划和架构理念的同时，也带来了服务运行和管理上的额外复杂性。在基于容器的微服务架构中，由于服务运行的位置、数量和时间的不确定性，传统用于假造机的性能监控和日记网络方式很难顺应容器应用动态变革的特点，那么怎样通过现有的开源工具对集群中的容器举行监控和日记管理呢？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的Fluentddriver直接定向搜集，但是搜集的日记Dockerlog下令是看不到的。对用户而言，可以根据实际的应用产物，对这两种方式举行选择。
获取架构师实践日第七期视频回放链接，请在七牛云公众号背景复兴关键词：71
「七牛架构师实践日」——这里只谈架构
七牛架构师实践日是由七牛云发起的线下技能沙龙活动，连合业内资深技能大牛以及各大巨头公司和创业品牌的良好架构师，致力于为业内开辟者、架构师和决定者提供最前沿、最有深度的技能交换平台，资助各人知悉技能动态，学习履历结果。
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论