微服务:
微服务是一种架构,这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务,一个服务通常实现一组独立的特性或功能,包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机,同一个系统和同一个应用服务器中。
为什么是微服务?
单体应用:

优点:单一架构模式在项目初期很小的时候开发方便,测试方便,部署方便,运行良好。
缺点:应用随着时间的推荐,加入的功能越来越多,最终会变得巨大,一个项目中很有可能数百万行的代码,互相之间繁琐的jar包。久而久之,开发效率低,代码维护困难。若想用一个新的技术,新的架构或者语言,基本是不可能的。
微服务架构应用:

优点:
将服务拆分成多个单一职责的小的服务,进行单独部署,服务之间通过网络进行通信,每个服务应该进行各自团队的自治。实现了服务之间的松耦合 。
缺点:
开发人员要处理分布式系统的复杂性,多五福运维难度,随着服务的增加,运维的压力也在增大。
架构的演变
单一应用架构(orm)
All in one application 起初当网站流量很小的时候,将所有功能都写在一个应用里面,对整个应用进行部署,以减少部署结点和成本。对于整个架构简化增删改查的工作量的数据访问框架是关键。

垂直应用架构(mvc)
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,提升效率的方法之一是将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的web框架是关键

分布式服务架构(rpc)
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务网中心,是前端应用能更快速的相应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架是关键。

微服务架构(soa)
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心是关键

微服务架构将大型应用拆分为多个独立的服务,每个服务专注于特定功能,通过API通信。相较于单体应用,微服务提高了开发效率和代码可维护性,但增加了分布式系统的复杂性和运维挑战。从单一应用架构到微服务架构的演进,旨在应对不断增长的业务需求和复杂性。
272

被折叠的 条评论
为什么被折叠?



