过年回来了，也休息够了，去年年会上该吹的牛逼也都吹的很到位了，年假回来，是该着手兑现的时候了。废话不多说，走起！
公司的项目，在设计之初其实就一定程度的引入了服务的概念，当时的出发点更多的是因为：团队协同和项目进度分期，不过还有一个重要的原因，是因为要完成的目标有点太大太虚，很多细节不可能一次性全部想到位，所以就采用了把大系统拆成一个一个的小系统来完成，这样来做，系统之间自然就产生了通信的必要性。
期初为了快速搭建原型和团队成员的技能分布，选择使用php作为开发语言。确实也在初期达到了快速开发的目的，拿到了一血后也踏上了小系统逐渐变大的不归路。系统和系统之间的通信使用的就是简单的http+cache，简单粗暴能运行，是当时的重要哲学。
工期的紧张，人员流动，再加上员工心态和情绪的波动等原因，映射在项目上就会成为功能缺失，代码质量下降，依赖混乱，抽象不足等。除此之外，开发人员毫无节制的重复发明服务，使前面说到的问题进一步放大，一度成为毫无解决希望的技术债务。
由于公司业务变更，团队大部分成员投入到了一个新项目的开发上，这给这个项目和我都留出了一个非常完美的空档期，在获得了领导的授权后，我调整状态，踏上了系统重构的大道，也就产生了该系列文章。
其实早在13年后半年，项目组开会时就已经提到了关于服务化的设想，无奈当时并没有如今这样好的条件，也就不了了之。经历了14年的php转java，项目soa的条件逐渐成熟，是时候大展身手了。
依照前辈大神们的心得体会，需要在项目中首先确定一些有价值的业务进行SOA重构，什么叫有价值的？就是那些项目的核心模块么？
其实不全对，为了保证开门红，建议从项目中选择一些复杂度相对较低，重要度适中的一些模块来下刀，避免造成骑虎难下的尴尬局面，而且也可以更快的积累经验和信心，当然，也不要选择太简单太无所谓的模块来搞，这样既无法积累经验，也不利于团队推广。
那么我们该怎么选呢？我考虑了一下，决定以下面三个维度来作为选择的基准：
- 重要度：■ ■ □ □ □
- 复杂度：■ ■ □ □ □
- 频度：■ ■ ■ □ □
确定了这个标准后，我又进一步给自己安排了一个重构流程：
- 从需求书中寻找服务，并依照基准分类
- 梳理服务之间的关系，确定哪些是原子服务，哪些是复合服务
- 设计服务接口，以及协议类型（RPC？REST？）
- 代码实现
了解soa的童鞋，自然会问：你基于哪些技术来实现SOA？其实SOA的技术骨架也无非就是：服务发现，服务治理，数据通信等几大块，商业的解决方案中还会提供强大的服务总线，工作流等功能（这些仅代表我个人理解，不喜勿拍）。
相信关注我博客的朋友肯定知道我要使用的框架是什么，没错，就是dubbox，其细节请参看我博客中的相关文章。
我们引入dubbox的目标，不仅是改善系统间依赖的混乱局面，还要标准化一些开发流程，提升开发效率，提升系统的可用性，性能，可伸缩，扩展性，重用性等。
下面我们具体来定一些指标，由于缺乏经验和相关数据，所以列出的指标会过于笼统，不过有生于无嘛。
- 标准化服务开发流程，从流程视角杜绝服务的重复，以及确保服务质量；
- 提高服务的可用性，确保每个服务都有冗余，并提供针对应用的监控工具；
- 提高服务响应时间，根据实际的复杂度来度量，尽可能保证服务响应时间在100ms--500ms之间（不启用缓存的情况下）；
- 提升代码的重用性，并尽可能降低代码的耦合度；
- 提升代码的质量，提供更完善的代码检测工具和流程。
好了，日后根据工作的进行，再逐步细化指标，总之大的方向就这些。