什么是微服务架构
微服务架构(Microservices Architecture)是将应用拆分成小业务单元进行开发和部署,使用轻量级协议通信,通过协同工作实现应用逻辑的架构模式。
灵活、稳定、省资源是微服务架构的主要优点——
- 可独立部署、升级、替换、伸缩
- 自由选择开发语言
- 高效利用资源
- 故障隔离
服务多、管理难度大是微服务架构的不足之处——
- 服务多,带来更多操作
- 管理复杂度提升
- 部署难度加大
但总体来说,微服务架构是非常吸引人的,否则也不会得到像Twitter、Netflix、Amazon、eBay等知名大厂的青睐。
微服务架构模式
微服务架构模式主要可分为:
- 聚合模式
- 代理模式
- 资源共享模式
- 异步消息模式
聚合模式
聚合模式即多个服务聚合到一个服务,称之为聚合服务。聚合服务最常见的表现是Web服务,主要功能为页面表现,后端服务为纯业务功能服务。也就是说,聚合模式下扩展业务只需增加一个新的后端微服务即可。
聚合服务符合DRY原则,可以是一个更高层次的组合微服务,增加业务逻辑后进一步发布成一个新的微服务,同时每个服务都有自己的缓存和数据库。
聚合模式是微服务架构中最常用的模式。
代理模式
代理模式是一种特殊的聚合模式,即对外将服务统一包装。代理模式可以仅仅委派请求,也可以进行数据转换工作。
我们可以将代理模式比做通过收发室统一收发信件的小区,无论是外部请求还是内部数据服务,均由代理处理。
资源共享模式
微服务架构的资源共享模式可实现部分业务的逻辑分离、数据共享。
资源共享模式常用在“一体化架构”向“微服务架构”迁移的过渡阶段,以及有数据一致性要求的两个服务。
异步消息模式
微服务架构的异步消息模式适用于不需要同步的场景,如任务型服务,利用消息队列代替其他微服务架构模式所采用的REST请求及响应。
微服务架构带来的挑战
-
服务部署的挑战
每个服务都需要独立的代码管理、版本管理、编译构建、测试环境部署、生产环境部署、代码回滚等,人工管理大量微服务几乎是一个不可能完成的任务。
-
服务绅缩的挑战
无状态服务需要配置负载均衡和增加节点,有状态服务需要扩充单个服务的资源。为了减少资源浪费,开发者需要监控每个服务,并在必要的时候减少节点和资源。
-
服务高可用的挑战
每种服务的高可用策略都不一样,这其中无状态服务的管理相对简单,而每个有状态服务的管理则是一个难题。
-
服务容错的挑战
任何一个服务的可用性都不是100%的,在分布式系统中,当某个依赖服务不可用时,系统自身也将不能工作。尤其是依赖大量服务的复杂的分布式系统,以来服务的可用性加上网络不稳定的因素,系统自身的可用性很可能无法得到令人满意的保障。
-
依赖关系的挑战
如果将依赖配置文件写在代码中,需要重新部署才能生效,而配置文件还可能会污染代码。
-
服务监控的挑战
监控CPU还是负载?大量微服务的出现也是对服务监控的严峻考验。
好雨的微服务架构解决方案
好雨的微服务架构解决方案(www.goodrain.com)核心思路为——
- 简化用户操作
- 微服务内部封装、整体对外
- 包装技术、服务业务
好雨云底层是通过Docker实现,并尽可能做到让用户感受不到Docker的使用体验。在好雨云,复杂特性被包装在了内部,通过服务整体对外,用户无需管理计算资源和网络资源。
服务部署
好雨云支持Java、Python、PHP、Ruby、Golang,Node.JS等主流开发语言,并支持Github、好雨托管仓库等代码仓库。
服务伸缩
好雨云支持服务伸缩,其中水平伸缩用于无状态的Server和Worker类服务,垂直伸缩用于有状态的服务。
部分有状态服务支持水平分区(Sharding),用户只需要调整节点个数就可以了。
服务高可用
好雨云通过高可用调度器,使无状态服务、有状态服务具备高可用特性。
依赖关系
好雨云的依赖关系解决方案类似于Spring的依赖注入,参数通过环境变量实现,调整服务的依赖关系只需要界面点击即可完成。
服务容错
好雨云的服务容错原理类似于保险丝,当某一服务变慢,达到断路器的阀值,该服务将自动下线,不至于影响其他服务,而当延迟变小时,该服务逐步恢复。
使用异步也可以达到服务容错的效果,具体可参考CQRS模式。
服务监控
好雨云将平均响应时间、吞吐率、在线人数等业务指标用于服务监控。
用业务监控替代技术监控,实际场景中的服务监控得以变得简单而易于理解。
实时性能分析
最慢的SQL语句不一定是对数据库影响最大的,好雨云的实时性能分析通过CEP+log实现,从实际出发解决问题,开发者可以很直观的了解当前对系统影响最大的URL是哪个。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。