微服务集成:模式、技术与关键要求
1. 微服务与ESB的集成
在某些微服务实现中,会将企业服务总线(ESB)重新引入微服务架构,把ESB作为运行时来实现服务集成。多数情况下,ESB部署在容器中,以服务特定用例的服务集成。然而,ESB存在固有局限性,比如体积庞大,难以作为容器运行;基于配置的集成方式对开发者不太友好等。有些ESB供应商会推广这种模式,但在集成微服务时应尽量避免。不过,也有对容器友好的轻量级ESB版本,可用于独立集成微服务,这比使用中央ESB要好得多。
2. 使用同质技术构建所有微服务
“智能端点与哑管道”意味着原本ESB开箱即用的酷炫功能,现在必须作为服务逻辑的一部分来实现。开发微服务时,并非所有微服务都相似。有些服务更侧重于业务逻辑和计算,而有些则更关注服务间通信和网络调用。如果坚持使用单一的同质技术集来构建所有微服务,那么构建微服务集成的核心组件将比关注服务的业务逻辑付出更多努力。例如,服务集成通常需要服务发现和弹性通信(如断路器),有些框架或编程语言可开箱即用地提供这些功能,而有些则不能。因此,架构应足够灵活,以便为工作选择合适的技术。
3. 组织微服务
根据微服务的交互识别不同类型的微服务,并使用最合适的技术来构建它们,是构建成功微服务架构的关键。从服务功能和粒度来看,可将微服务分为以下几类:
- 核心服务 :细粒度、自包含(无外部服务依赖),主要由业务逻辑组成,几乎没有或很少有网络通信逻辑。由于这些服务没有显著的网络通信功能,可自由选择任何能实现服务业务逻辑的服务实现技术。它们可能有自己的私有数据库,用于构建业务逻辑,这类微服务可归类为核心或原子微服务。
超级会员免费看
订阅专栏 解锁全文
170万+

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



