引言
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。
微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
微服务的性能监控与日志收集实现
微服务的复杂性
微服务相对于单体应用,在灵活性、可扩展性上要高很多,但是它的高灵活性是有一定代价的,这个代价主要在它的复杂性上。
微服务的复杂性体现在多个方面,首先从软件管理上来说,要管理一个微服务架构的产品,比管理一个单体应用产品要复杂得多,因为你需要管理很大的一个团队,并且每个团队有着不同的架构。对此,很多时候我们需要让开发者有自主的管理权,让他们可以自己做运维做部署。除此之外,对于服务调试来说,微服务的调试也比单体调试复杂得多,一旦一个产品线上出现问题,就需要开发团队更好更默契地去协调团队与团队之间服务的划分和调试。
另一个微服务的复杂性,还体现在微服务的基础设施上。以前单体应用升级服务的时候,平台可以决定什么时候能部署,但是对于SOA甚至微服务的架构来说,从平台来看,它所认为的每一个服务的部署基本上是无序的,它无法预测一个服务在什么时候被部署、部署几个、需要多少资源等等