ESB zone

SOA，想说爱你不容易

今日看到eBay的一篇架构实践文章，想起了最近1年，我们公司向SOA迈进的一些方面。
驱动我们公司进行SOA的原因思来有如下一些方面：

• 代码增长太快，系统地扩展性太差；开发过程中，往往由于一个小的变动，就会重新发布整个系统
• 系统庞大，功能错综交叉，还在不断的堆积新功能，耦合度递增
• 业务部门对敏捷性的要求，市场是变化的（市场变化的速度加快了，竞争对手创新的速度也加快了），产品也需要能够适应变化
• 业务需求增长太快（市场变大了），同时进行的并发项目太多，非但进度缓慢，而且代码合并，集成测试都带来很大挑战；而且许多需求被压制，引起业务部门的不满意
• 一个系统容易掩盖业务的本质，使我们不能很好的分离业务逻辑和产品（一个业务逻辑，可以使用多种包装方式形成不同的产品，例如：登录业务，可以由weeb登录产品，wap登录产品，终端登录产品，接口登录产品等。）
• 把一些本来属于产品特有的逻辑也混杂在业务逻辑中，使得业务本质模糊，代码丑陋等等
• 每次启动工程都需要2-5分钟，所有人都已经不能忍受
• 系统发布计划越来越复杂，发布频率越来越高，稳定性变得越来越不可控
• 组织结构频繁变动
• 业务核心随着战略的变化，逐步演变；系统由单一核心业务向多个核心业务为中心的模式展开
• 随着销售的引入，产品化的需求变得很强烈
• 管理制度发生了变化，条例（安全相关、行业法规相关，法律相关）更加严格，细化
• 计划引入项目成本考核，目前状态下的成本明显偏高，架构必须为成本的降低做出贡献，提高资源生产率
• 业务监控，管理的需求提上了日程
• 各种规则、架构约束力的作用日渐消弱，系统逐步向混乱的方向演变。
• 业务系统和管理系统存在两套代码的现象，增加了业务逻辑不一致的几率，代码维护成本（例如Fix业务BUG）随着业务的复杂递增，测试成本也随着递增
• 开放平台战略的确立，要求业务必须标准化，服务化
• 等等

当然了，我们架构组自身也实在无法忍受。

采取如下策略，历时一年，逐步SOA化（社会主义初级阶段）。

1、首先进行业务的服务化，把我们的系统划分为几个核心业务块，然后挑选其中的一块业务（例如：会员相关业务）进行服务化，逐步把几大业务搞定。

2、第一块业务服务化的同时，研究相关的基础技术。例如：ESB、分布式事务、OSGI框架、开发模式、系统部署模式、业务用例如何向系统用例转化、业务粒度的设计原则等。同时研究对立部署业务单元对性能、可靠性、稳定性方面的影响。

3、随后服务化的时候，引入可靠异步模式，包括业务流程异步化。

上面的过程和eBay架构实践中介绍的几点有一些相似性。

Scalability Best Practices: Lessons from eBay一文

• Best Practice #1: Partition by Function

• Best Practice #4: Decouple Functions Asynchronously

• Best Practice #5: Move Processing To Asynchronous Flows

在我们进行SOA的过程中，我们初步实现了按照大的业务快进行切分，还未能够实现对更细的功能点进行梳理。一方面是为了避免风险，另一方面我们也未能从业务上搞清楚再细粒度的功能点如何划分。
4，5两个技巧提到异步，在这二点上我们进行了一些有益的尝试，但还是未能破除目前太多的同步调用现象。究其原因，我们未能从业务上定义清楚更细粒度的功能点，以及它们之间是否适合异步。

从目前实践效果来看，我们解决了当时驱动我们SOA化的一些方面，同时引入了如下困难：

1. 测试的困难，每次项目分支，由于其依赖其它业务核心，导致需要同时切出多个分支，申请多套环境
2. 开放的困难，很多程序员不能理解这次调用到底访问的是谁？
3. 版本问题
4. 服务的监控和管理
5. 最头痛的是：业务服务思想的延续性，已经出现部分业务核心偏离了当时的业务分类原则
6. 产品层存在粒度过细的信息查询，没有考虑到SOA场景下，产品层信息使用的策略
7. 技术体系相对复杂化了，开发、测试需要重新学习这种架构
8. 等等

关于业务异步化：从长远来看，业务异步化的研究，会给我们的产品化、开放化、SOA化、网格化计算提供有力的支撑，同时显著提升我们系统的扩展能力。但从另一个方面来讲，它给我们的程序员，业务分析人员带来的困惑也会更多。