微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
微服务中的spring-cloud
Spring Cloud是一个相对比较新的微服务框架,2016n年推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。
Spring Cloud 为开发者提供了在分布式系统(配置管理,服务发现,熔断,路由,微代理,控制总线,一次性token,全居琐,leader选举,分布式session,集群状态)中快速构建的工具,使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。
微服务架构
优点:
1. 技术异构性
在不同的服务中,可以使用不同的技术来各自开发,只要保证服务间能相互协作即可
2. 弹性
当微服务中的某一个服务不可用时,不会影响整个系统,只会影响相关功能不可用
3. 扩展
易于扩展,使用小的多个服务,更加易于扩展新的功能
4. 简化部署
某个服务的更新部署,不需要重新部署整个应用
5. 可组合
通过组合多个服务,可以提供一些新的功能
6. 可替代
因为每个微服务都比较小,重新实现某一个服务或者直接删除该服务都是可操作的
缺点:
1. 复杂度高
微服务间通过REST、RPC等形式交互,相对于单体模式,需要考虑被调用方故障、过载、消息丢失等各种异常情况,代码逻辑更加复杂。
对于微服务间的事务性操作,因为不同的微服务采用了不同的数据库,将无法利用数据库本身的事务机制保证一致性,需要引入二阶段提交等技术。
同时,在微服务间存在少部分共用功能但又无法提取成微服务时,各个微服务对于这部分功能通常需要重复开发,或至少要做代码复制,以避免微服务间的耦合,增加了开发成本。
2. 运维复杂
在采用微服务架构时,系统由多个独立运行的微服务构成,需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。
3. 影响性能
相对于单体架构,微服务的间通过REST、RPC等形式进行交互,通信的时延会受到较大的影响。