什么是容器和微服务中的可观测性？

容器和微服务中的可观测性暴露了产中应程序的状态，因此开发员可以更好地识别和解决性能问题。
容器服务（例如 Docker、Kubernetes 等）和微服务解决了停机时间增加的险以及与单体软件相关的其他问题，其中对单个代码库的任何更改都会影响整个应程序及其依赖项。容器和微服务将应程序分解为独的服务，允许开发员修改和重新部署特定服务不是整个应程序。
然，基于容器的架构带来了新的挑战。相互依赖的微服务通常分散在多个主机上，随着基础设施的扩展，产中微服务的数量也在增加。这使得开发员很难知道当前在产中运的内容，从导致更的交付周期、停机时间和其他问题。
可观测性解决了这些挑战，提供了分布式系统的可性，帮助开发员更好地了解应程序的性能和可性。在发故障时，它提供了快速查明和调试或修复问题所需的控制。

早在2013年的时候，docker就已经发行，然而那会还是很少人了解docker。一直到2014年，Martin Fowler提出了微服务的概念，两个不相干的技术终于走在了一起，创造了今天的辉煌！

近几年来，很多互联网关系开始跟风，构建docker+微服务的架构体系。然而，根据笔者观察发现，有些童鞋在使用过程中，只是会用，而根本不了解为什么使用docker，反正对他们来说，公司让用就用！而某些公司呢，虽然用上了docker，然而运维方式并没有发生改变，白白浪费了docker的大好性能

过去:曾记得12年那会，部门要上一个项目。那会，我是这么干的。直接去线上服务器，拷贝一个tomcat，然后改端口号，然后部署应用到webapps文件夹下，重启就好。而且我可以摸着良心说，现在还有很多传统企业是这么做的。
那么这么做的缺点？

很明显，应用之间相互影响。一个应用出现问题，该应用把线程池给拖垮了，这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐。如果还采用这种部署方式，你的应用和某个坑爹团队的应用部署在了同一台服务器上，至于结果，我相信你懂的。

现在:用上了docker容器后，将Docker可以将我们的应用程序打包封装到一个容器中，该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离，在容器中的 *** 作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形！

容器
同时处理很多项微服务可能会十分复杂，因为每个微服务的编程语言可能不一样，可能需要不同的应用服务器（最好是轻量级的服务器），也可能使用不同的库。但如果我们将每个服务都当做容器来包装，那么这些问题都会迎刃而解。我们只需要运行容器（例如用Docker运行容器），其他需要的东西统统都在容器内部了。
容器本身是自给自足的，其内部包含我们需要的所有东西（除了内核kernel），此外各个容器单独运行并不可改变。而自给自足则意味着容器通常具有以下几个部分。
运行时间库（运行应用时所需的JDK、Python或其他库）
应用服务器（Tomcat、nginx等）
数据库（最好是轻量级的）
工件（JAR、WAR、静态文件等）

一个或多个微服务。
在同一个容器内同时运行多个微服务进程，或是使用多个容器共同构建一个分布式的微服务体系。基于容器技术，可以更加轻松地打包、分发、部署和管理微服务，以及更好地支持微服务架构下的自动化运维和容错性能优化等需求。
微服务是一种软件架构风格，旨在将单个应用程序构建为一组小型的、互相协作的服务，每个服务都在自己的进程中运行，使用轻量级通信机制进行通信。

---