为什么需要微服务,那么使用微服务就一定好么

【为什么需要微服务,那么使用微服务就一定好么】这种情况下的处理措施是原来的微服务划分太细,需要将两个微服务合并 。微服务的局限性在于,微服务因为服务量和管理成本的增加,很难以整体架构的形式支撑 。个人认为微服务更适合快速响应,比如 。还是我原来的判断标准,即两个微服务对应的后台数据表有30%以上需要两个微服务交叉访问,那么我认为这两个微服务本身就是高度耦合的 。
微服务为什么不需要esb?

为什么需要微服务,那么使用微服务就一定好么


首先我个人不认为微服务不需要ESB 。两者是相互融合相互配合的,在不同的应用场景下发挥自身的优势,共同助力企业的发展 。并且在微服务快速兴起的现在,ESB本身也在不断完善调整,比如,数通畅联的AEAI ESB本身就支持微服务架构的开发,实现了跟微服务架构的融合 。其次微服务是近几年比较流行的新兴架构,更多的采用Restful接口而不是WebService,微服务类似于七巧板的组件,以小粒度为用户提供服务,用户可以根据自身的喜好自由组合配置服务组件,灵活的进行扩展 。
但是微服务的局限在于因为服务量增多,管理成本增加,微服务难以用整体架构的形式进行支撑,个人认为微服务更加适用于快速响应如APP,前后端分离架构,互联网模式交互 。ESB企业服务总线作为SOA中重要的承载物,可以说是企业信息的龙骨,通过ESB实现服务的消费者及提供者之间的联通与管理,实现服务的治理重组编排和代理等,可以有效的支撑企业级的信息化集成架构的落地 。
微服务架构为何需要搭配API网关?
为什么需要微服务,那么使用微服务就一定好么


微服务架构可以理解为一种架构风格,将一个大型复杂软件应用由一个或多个微服务组成 。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的 。每个微服务仅关注于完成一件任务并很好地完成该任务 。在所有情况下,每个任务代表着一个小的业务能力 。而API网关则是负责提供一套单一且统一的API入口点,其跨越一个或者多个内部API 。
其通常亦设定了层速率限制与安全性机制 。两者搭配有如下几点优势第一可以隔离内部与外部的联系,保证内部服务和数据信息的安全,外部无法直接访问到内部数据和服务,隔绝了对内部服务和数据的窥探第二API网关可以提供一层有利的保护罩,保证内部服务和数据不会受到攻击第三API可以支持多种协议的适配,可以更好的协调微服务的协议形式,使内部的服务之间不必拘泥于一种协议的开发,提高了服务开发的灵活性第四API网关可以进行协议适配安全验证等,降低了对微服务开发对外部的适配,使之可以更贴近实际核心业务的开发 。
系统软件架构中,现在很流行微服务,那么使用微服务就一定好么?微服务有哪些缺点呢?
为什么需要微服务,那么使用微服务就一定好么


下面简单回答下这个问题 。在回答这个问题前还是先回顾下微服务架构 。微服务架构概述微服务架构本质是单个业务系统彻底的组件化前端,逻辑层,数据库解耦,同时相互之间通过轻量的服务接口和协议进行协同 。这和很早就谈到的组件化架构思想是一致的,实现微服务架构后,你会看到没有传统业务系统的概念了,有的只是微服务模块或小应用 。
微服务架构最近又炒的相当活,很多人会说SOA过时了,ESB过时了,甚至还有人用微服务架构去彻底的否定SOA和ESB,这些都是相当危险的信号 。在我12,13年写企业私有云PaaS平台的一系列文章的时候,已经提出了业务能力组件化,组件服务化的微服务架构思想,但是实际应用实施效果并不太理想 。我们可以先看下从单体应用到微服务架构的变化图 。

推荐阅读