过年回来了,也休息够了,去年年会上该吹的牛逼也都吹的很到位了,年假回来,是该着手兑现的时候了。废话不多说,走起!

背景

公司的项目,在设计之初其实就一定程度的引入了服务的概念,当时的出发点更多的是因为:团队协同和项目进度分期,不过还有一个重要的原因,是因为要完成的目标有点太大太虚,很多细节不可能一次性全部想到位,所以就采用了把大系统拆成一个一个的小系统来完成,这样来做,系统之间自然就产生了通信的必要性。

期初为了快速搭建原型和团队成员的技能分布,选择使用php作为开发语言。确实也在初期达到了快速开发的目的,拿到了一血后也踏上了小系统逐渐变大的不归路。系统和系统之间的通信使用的就是简单的http+cache,简单粗暴能运行,是当时的重要哲学。

工期的紧张,人员流动,再加上员工心态和情绪的波动等原因,映射在项目上就会成为功能缺失,代码质量下降,依赖混乱,抽象不足等。除此之外,开发人员毫无节制的重复发明服务,使前面说到的问题进一步放大,一度成为毫无解决希望的技术债务。

由于公司业务变更,团队大部分成员投入到了一个新项目的开发上,这给这个项目和我都留出了一个非常完美的空档期,在获得了领导的授权后,我调整状态,踏上了系统重构的大道,也就产生了该系列文章。

其实早在13年后半年,项目组开会时就已经提到了关于服务化的设想,无奈当时并没有如今这样好的条件,也就不了了之。经历了14年的php转java,项目soa的条件逐渐成熟,是时候大展身手了。

计划

依照前辈大神们的心得体会,需要在项目中首先确定一些有价值的业务进行SOA重构,什么叫有价值的?就是那些项目的核心模块么?

其实不全对,为了保证开门红,建议从项目中选择一些复杂度相对较低,重要度适中的一些模块来下刀,避免造成骑虎难下的尴尬局面,而且也可以更快的积累经验和信心,当然,也不要选择太简单太无所谓的模块来搞,这样既无法积累经验,也不利于团队推广。

那么我们该怎么选呢?我考虑了一下,决定以下面三个维度来作为选择的基准:

  • 重要度:■ ■ □ □ □
  • 复杂度:■ ■ □ □ □
  • 频度:■ ■ ■ □ □

确定了这个标准后,我又进一步给自己安排了一个重构流程:

  1. 从需求书中寻找服务,并依照基准分类
  2. 梳理服务之间的关系,确定哪些是原子服务,哪些是复合服务
  3. 设计服务接口,以及协议类型(RPC?REST?)
  4. 代码实现

技术选型

了解soa的童鞋,自然会问:你基于哪些技术来实现SOA?其实SOA的技术骨架也无非就是:服务发现,服务治理,数据通信等几大块,商业的解决方案中还会提供强大的服务总线,工作流等功能(这些仅代表我个人理解,不喜勿拍)。

相信关注我博客的朋友肯定知道我要使用的框架是什么,没错,就是dubbox,其细节请参看我博客中的相关文章

指标

我们引入dubbox的目标,不仅是改善系统间依赖的混乱局面,还要标准化一些开发流程,提升开发效率,提升系统的可用性,性能,可伸缩,扩展性,重用性等。

下面我们具体来定一些指标,由于缺乏经验和相关数据,所以列出的指标会过于笼统,不过有生于无嘛。

  1. 标准化服务开发流程,从流程视角杜绝服务的重复,以及确保服务质量;
  2. 提高服务的可用性,确保每个服务都有冗余,并提供针对应用的监控工具;
  3. 提高服务响应时间,根据实际的复杂度来度量,尽可能保证服务响应时间在100ms–500ms之间(不启用缓存的情况下);
  4. 提升代码的重用性,并尽可能降低代码的耦合度;
  5. 提升代码的质量,提供更完善的代码检测工具和流程。

好了,日后根据工作的进行,再逐步细化指标,总之大的方向就这些。