引言
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
微服务的性能监控与日志收集实现
微服务的复杂性
微服务相对于单体应用，在灵活性、可扩展性上要高很多，但是它的高灵活性是有一定代价的，这个代价主要在它的复杂性上。
微服务的复杂性体现在多个方面，首先从软件管理上来说，要管理一个微服务架构的产品，比管理一个单体应用产品要复杂得多，因为你需要管理很大的一个团队，并且每个团队有着不同的架构。对此，很多时候我们需要让开发者有自主的管理权，让他们可以自己做运维做部署。除此之外，对于服务调试来说，微服务的调试也比单体调试复杂得多，一旦一个产品线上出现问题，就需要开发团队更好更默契地去协调团队与团队之间服务的划分和调试。
另一个微服务的复杂性，还体现在微服务的基础设施上。以前单体应用升级服务的时候，平台可以决定什么时候能部署，但是对于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语言，它使得索引不能在每一个客户端去做，因为会占用很大的的内存。
Fluentd的方案与Logstash差不多，但是它可以省掉Indexer这层，而且它的核心代码是C++写的，从效率上说会比Logstash高很多。除此之外，Fluentd是除了Splunk以外唯一一个在Docker官方日志驱动里面的工具。一般来说,日志收集是通过收集文件的方式进行的，因为Docker会默认将容器的日志放到一个指定的目录里。Logstash会去搜集目录里面的日志，但是存在一个问题，就是Logstash在搜集的时候是每隔一定的时间在目录里面做一次查询，这样很可能因为监测的服务出故障造成日志丢失。Fluentd则不仅支持Logstash那种文件的方式去搜集日志，还可以通过Docker的Fluentd driver直接定向搜集，但是搜集的日志Docker log命令是看不到的。对用户而言，可以根据实际的应用产品，对这两种方式进行选择。
总结
以 上就是我对Java大型互联网-不一样的微服务架构性能监控系统与日志收集实现 问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！
最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!
想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：（666 必过）欢迎大家的加入哟！