微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立的数据库。
传统的单体架构是以整个系统为单位进行部署,而微服务则是以每一个独立组件(例如用户服务,商品服务)为单位进行部署。 图中左边是单体架构的集群,右边是微服务集群。 什么意思呢?比如根据每个服务的吞吐量不同,支付服务需要部署20台机器,用户服务需要部署30台机器,而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。我们可以单独的部署这些服务。
微服务设计的原则之一,就是每一个微服务拥有独立的数据源,假如微服务A想要读写微服务B的数据库,只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。
微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构,前端有前端的团队,后端有后端的团队,DBA有DBA的团队,测试有测试的团队。 而微服务的设计思想对团队的划分有着一定的影响,使得团队组织架构的划分更倾向于垂直架构,比如用户业务是一个团队来负责,支付业务是一个团队来负责。
强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题,提供落地对应服务的一个服务应用,狭意的看,可以看作Ecipse里面的一个个微服务工程或者Module
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTfulAPl)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
SOA架构是一种粗粒度、松耦合的服务架构,其更多的是强调异构系统之间的服务通信。 SOA是什么样子呢?可以是下面这样的Web Service: 也可以是下面这样的ESB企业服务总线: SOA架构强调的是异构系统之间的通信和解耦合,而微服务架构强调的是系统按业务边界做细粒度的拆分和部署
微服务架构算是SOA架构的一种拓展,主要关注的是服务个体的独立性、拆分粒度更小。相对于SOA架构来说,微服务拥有以下优势: 微服务强调更深层次的组件化和服务化,每个微服务都可以拥有独立的运行空间,确保每一个服务组件可以作为单独的产品进行发布。 微服务抛弃了传统SOA笨重的企业服务总线,对外发布强调使用HTTP REST API的接口发布形式。 感谢您的阅读~~