组件化与服务化

微服务架构无疑是现在最火热的软件架构模式。在这样的大背景下，我们会持续在推进应用架构的演进和改造。我们在业务量和负载持续低水平运行的情况下，习惯性采用单体架构。但是当业务量和负载上升以后，我们的软件越来越复杂，代码量越来越大，开发人员也越来越多，业务的改动也会越来越频繁。在这种情况下，如果软件架构不做改进，我们的项目或者软件 最终就会像柴火垛一样变得杂乱无章 。同时，我们也一定会想到采用在架构层加大复用力度的措施， 组件化和服务化 无疑都是可以达成这一目的的手段。组件化与服务化应该如何选择是一个难题。

一、厘清概念

既然谈到了组件化和服务化，那我们先来看看他们的概念有什么联系和区别。

组件化和服务化的目的是一样的，都是要避免重复性工作，实现复用。具体来说又有一些不同， 组件化架构关注软件代码和技术层的复用，服务化架构更关注系统运行和能力层的复用 。

1、组件化架构

组件化，即把系统内部的一些公共功能模块或者对外部系统调用的一些逻辑方法封装成一个独立jar包，有需要的系统直接依赖该jar包来使用相应的服务。

通常一个项目在平台的标准化建设基础上，会开始进行通用性组件的建设。 通用组件一般包括技术组件和业务组件两部分 。

技术组件主要是针对常用的工具和技术类共性代码进行封装，尽可能的将共性技术能力进行最大程度的复用，保证研发的统一性，便于后期运维和持续迭代。技术组件一方面能够提升单一功能的研发效率，降低重复性工作，另外一方面能过实现技术的统一，避免反复调式，提高效率和代码质量；

业务组件主要是基于行业的业务特点，针对共性服务和能力进行拆分，从而形成能力层的复用，便于进一步的集成。业务组件的形成，一般有两种方式，一是新人新办法老人老办法，根据新项目逐步积累和沉淀，二是对旧项目进行彻底的改造。前者便于开展，后者成本过高短期不易见效，最好是根据实际情况综合考虑，在对研发模式进行改进的同时，逐步对原有应用系统所形成的成果抽取到新项目中去。

2、服务化架构

服务化，即把系统内部的一些公共功能模块或者对外部系统调用的一些逻辑方法独立拆分为一个服务，该服务再对外暴露统一的接口供所有有需要的服务去调用。

区别于组件化的jar依赖，所谓服务，就是可以单独运行，并且对外提供功能性服务的一种形式。 把一个复杂项目拆分成若干个服务，当某一个服务宕机时不会影响整个系统。如果没有服务化，所有功能的新增都要影响全局，采用了服务化就对故障域进行了隔离和划分。

此外，服务化架构一般主要针对大型软件进行部署，可以充分解决并发和扩展的问题。所以服务化架构其实不具备普遍性，需要是系统发展到一定阶段，复杂性上升到一定程度，小系统贸然做服务化拆分，运维的复杂度和运维成本会成倍增加。

二、适用场景分析

1、各自优劣势分析

组件化和服务化各自有不同的出发点，自然也就有不同适用场景。但是谈适用场景前肯定要先分析各自优劣势：

1）组件化的优势在于直接通过iar包实现服务的调用，服务调用性能较高，性能损失较少，对性能要求的场景比较合适；同时由于采用jar包的方式，不需要独立部署，能够节省服务器资源，尤其是在高并发场景下，本就捉襟见肘的算力资源可以得到一定程度的释放。

2）组件化的劣势在于，首先是可维护性差，组件本身实现的逻辑如果发生变化，除组件本身需要升级以外，所有jar包有依赖关系的服务和模块都要一起升级。同时这种升级也带了风险和高昂的成本。

3）服务化的优势在于由于服务化的封装可以屏蔽服务内的细节，可以实现独立部署，良好的隔离性实现了功能之间的解耦，可维护性好，大幅降低维护和开发成本。

4）服务化的劣势在于，存在额外的性能开销，而且服务的拆分粒度不好把握，过度的服务化会让系统变慢，而且服务之间关系的维护成本也会变得很高， 粒度的拿捏只能靠经验甚至靠玄学。 分布式节点的采用，导致复杂度的上升，分布式事务和一致性都是需要考虑的问题。

2、适用场景分析

从组件化的优劣势上可以看出，组件化主要适用于系统内部公共组件的剥离，还有就是高并发场景，由于组件化的性能上优势，可以考虑组件化降低性能和资源消耗，提升整体执行效率。还有就是组件化使用于算力资源不足的场景，不富裕那就省着点过呗。

服务化主要适用于系统内部数据库等组件的解耦，这种情况服务化是一个好选择。另外，系统外部复杂的第三方调用也是一个很好的场景，可以把外部服务调用单独分离出来，以降低系统复杂度。当然这种场景下，不能对性能有太多苛刻的要求，对服务调用链的延长也不能太敏感。

也有很多人可能会说，很多高并发的场景也再采用服务化架构，并没有觉得性能受损，也没觉得服务调用链变长有啥影响。那是因为采用很多分布式的措施去保障。

任何一种架构和技术，都有局限性，就像CAP原则，不可能同时满足一样， 更像你不可能让所有人满意一样 。