服务化，SOA，绝对是一个火热了N年的词，再加上各大互联网公司在讲各自的技术架构演进时，基本都会提到服务化，这个诱惑的很多人都想对系统做服务化的改造，但你真的需要服务化吗？
所谓的服务化，是指根据业务的职责划分为多个系统，系统之间的交互以服务的方式进行，这样的好处看起来就是系统的职责变得非常清晰。
但其实呢，服务化并不仅仅是一个纯粹的技术改造，服务化就意味着业务是由多个系统构成，这个时候首先会产生的第一个核心问题是需要有相应的人员来维护，在服务化之前，通常来说模式都是一个系统，所有的开发共同维护一个系统，而服务化拆成多个系统后，就不可能所有的开发再共同维护了，因此做服务化之前，首先要做的第一点是组织结构的调整要对应的准备好，所以其实如果开发人员不多的话，显然是没必要做服务化的，否则连开发的人都不够分，Jeff Dean在有一次的topic上讲到服务化带来的一个好处：easier to have many engineering offices around the world.
另外，有很多想做服务化的原因是觉得服务化后职责清晰，开发效率更高，但事实上是，服务化后变成了多个系统，很多时候会出现为了实现一个需求，需要改多个系统（尽管服务化本来是希望能减少这种现象，但事实上很难做到），协调多个团队，而在一个系统的情况下，通常是每个开发都为整个系统负责，所以在实现需求时是可以一个开发搞定，这样的效率其实通常是更高的，所以其实我始终认为，服务化了以后整个开发效率是一定程度下降的，但好处是它可以支撑很大规模的开发团队。
所以从上面大家可以看到，服务化是在发展到一定情况下才需要做的，我自己觉得触发要做服务化的主要原因会是这三个：1. 底层例如数据库连接到达上限 系统共用的底层资源在随着机器增加的越来越多时，一定会成为瓶颈，这种情况下服务化会带来帮助，当系统逻辑变简单的情况下，吞吐量自然也比较容易上升，这个时候使用底层资源的机器数自然可以大幅下降。
2. 开发人员规模庞大 当开发人员规模变大(100个左右)时，众多人共同维护一个系统会变得不可行，这个时候服务化可以产生巨大帮助，也会成为必须做的事情。
3. 业务多元化，共享的业务逻辑多 当业务朝多元化方向发展时，各个业务可能会有很多共享的业务逻辑出现，这个时候服务化会带来帮助，不过通常业务多元化也会自然带来开发人员规模庞大，不过这个方式在逐步发展中也会出现一些问题，但总体来说这种情况下服务化还是必须做的。
服务化改造还会带来其他一些问题，感兴趣的可以参见我以前写过的一篇《服务框架演变过程》
如果没有上面的那些原因的话，我的建议都是能不做服务化的话还是尽量不要做。
所以一个架构师在做架构改造的决定时，最重要的是要考虑全面（各种平衡），很有可能架构改造并不仅仅是技术层面的事，并且需要判断架构改造发生的合适时间点。
=============================欢迎关注微信公众号：hellojavacases
关于此微信号：分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test，以及和大家一起讨论一些Java问题或场景，这里只有Java细节的分享，没有大道理、大架构和大框架。
公众号上发布的消息都存放在http://hellojava.info上。
生活是一段奇妙的旅行，就在那一去无返的火车上。
