微服务(MicroServices)

本文介绍了微服务架构的基本概念及特点,阐述了如何通过服务拆分实现应用的独立部署与扩展,探讨了微服务架构的实际应用及其成功案例。

微服务Architecture(MicroServices)

微服务架构简单的定义

  采用一组Service的方式来构建一个应用,服务独立部署在不同的进程(Container)中,不同Service通过一些轻量级交互机制来通信,例如:RPC、API、HTTP等;Service可独立扩展伸缩,每个Service定义了明确的边界,不同的Service甚至可以采用不同的编程语言来实现,由独立的团队来维护。

  例如认证服务:用户登录和用户注册可以拆分为两个微服务。

微服务Architecture特征

传统组件是和应用一起运行在进程中,组件的局部变化意味着整个应用的重新部署。通过Service来实现组件,意味着将应用拆散为一系列的Service运行在不同的进程中,那么单一Service的局部变化只需重新部署对应的Service进程。另外将Service作为组件可以更明确的定义出组件的边界,因为Service之间的调用是跨进程的。

微服务架构应用

采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是,单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能,如果 A 功能发生变化时同时 B 功能也需要变化,那么 A 和 B 这两个功能应该被划在一个服务中。

微服务架构应用的成功经验近年已越来越多,例如国外的 Amazon,Netflix,国内如阿里都采用微服务架构取得了很多正面的成功案例。 但通过上文所述微服务架构特征看出,其实微服务架构模式有利有弊,需要根据实际的业务、团队、环境进行仔细权衡利弊。 其中的服务拆分带来的额外开发、测试、运维、监控的复杂度,在现有的环境、团队下是否能够很好的支持。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值