1. 前言
随着现在互联网行业的发展,越来越多的框架、中间件、容器等开源技术不断地涌现,更好地来服务于业务,实现业务并解决问题。然而面对众多的技术选择,我们要如何甄别出适合自己团队业务的技术呢?对于人来说,鞋子过大,可能影响奔跑的速度,鞋子过小,可能影响身体的成长。技术对于业务也是如此的关系。
所以,相对于技术的学习、搭建、使用、运维等技能,我们 对技术的甄别选择更是重中之重。那么本文要讲的Dubbox框架,又是如何在众多的服务框架中脱颖而出,被团队选中践行服务之路?
2. 服务
2.1 为什么要做服务
技术为业务而生,架构也为业务而出现。随着业务的发展、用户量的增长,系统数量增多,调用依赖关系也变得复杂,为了确保系统高可用、高并发的要求,系统的架构也从单体时代慢慢迁移至服务SOA时代,根据不同服务对系统资源的要求不同,我们可以更合理的配置系统资源,使系统资源利用率最大化。
- 单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。
此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 - 垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。
此时,用于加速前端页面开发的 Web框架(MVC) 是关键。 - 分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 - 流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。
此时,用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
平台随着业务的发展 从 All in One 环境 就可以满足业务需求(以Java来说,可能只是一两个war包就解决了);发展到需 要拆分多个应用,并且采用MVC的方式 分离前后端,加快开发效率;在发展到服务越来越多,不得不将 一些核心或共用的服务拆分出来,提供实时流动监控计算等,其实发展到此阶段,如果服务拆分的足够精细,并且独立运行,这个时候至少可以 理解为SOA(Service-Oriented Architecture)架构 了。
2.2 服务带来的挑战
当迎来服务SOA时代,我们面临要解决的问题会很多,比如:系统的复杂度上升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。那么面对这些问题为什么还要做分布式服务呢?因为在未来只有砥砺前行,才能走的更高更远。不过看到这些问题不要气馁,先不管这些问题,让我们一步步来梳理下现存有什么问题,我们要完成什么目标,问题自然会迎刃而解。
根据现在团队的业务系统情况,首先我们要梳理出现存的问题是什么:
- 多种调用传输方式:HTTP方式、WebService方式;
- 服务调用依赖关系:人工记录,查看代码分析;
- 服务调用性能监控:日志记录,人工查看时间;
- 服务与应用紧耦合:服务挂掉,应用无法可用;
- 服务集群负载配置:Nginx配置,存在单点问题;
在去选择技术框架时,技术框架最基本要解决上面现存问题,同时我们也要确认出我们的期望,要达到的目标是什么:
- 支持当前业务需求,这是最最基本的条件;
- 服务避免单点问题,去中心化;
- 服务高可用、高并发,解耦服务依赖;
- 服务通用化,支持异构系统调用服务;
- 服务依赖关系自维护,可视化;
- 服务性能监控自统计,可视化;
- 服务需自带注册、发现、健康检查、负载均衡等特性;
- 开发人员关注度高,上手快,简单轻量,低侵入;
还有最重要一点,这也是往往很多技术人员进入的误区,“对于技术,不要为了使用而使用,用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的,能快速方便的满足业务需求的架构才是好的架构。