脱离实际业务情况的架构都是耍流氓，所以不是所有的系统都必须服务，也不应该为了服务而服务。服务优势当企业面临单一应用的瓶颈问题时，可以果断采用服务转型。优点如下。在了解服务的好处之前，我们先来看看传统的系统架构是什么样子的。了解了传统架构的缺点之后，就很容易理解我们为什么要做服务了。
技术架构为什么要服务化？
关乎体量和需求的增长变化首先明确，服务化的本质是依托实际需求的。假如你的系统只有几十几百个人使用，在当下的技术架构中单体应用完全足够，这时候追逐服务化反而是一种舍本逐末，捡芝麻丢西瓜的举动了，为什么要服务化？因为单体应用面临越来越多的系统需求功能迭代、面对越来越多的用户使用，无法保证稳定性、可靠性、可扩展性。
还存在模块间流量不平衡，资源权重无法得到有效分配的一大批问题，伴随系统越来越庞大，彼此间耦合的调用关系到处都是，很有可能牵一发动全身。对产品的可维护性来说也变差了，服务化优势当企业面临单体应用的瓶颈问题是，可以果断采取服务化改造优势如下。1、减少耦合，梳理关系，2、明确服务重点，有侧重进行资源分配。3、减少单点故障发生，
为什么越来越多的系统在做服务化？服务化有什么好处？
首先要表明一个观点：脱离业务实际情况的架构都是耍流氓，所以不是所有系统都必须服务化，也不要为了服务化而服务化。在了解服务化的好处之前，让我们先看看传统的系统架构是什么样的，当了解传统架构的缺点之后，再去看看为什么要做服务化，就容易理解了，在单体服务的时代，我们是一台应用服务器，后面挂一台数据库。当访问量增多的时候，会引入负载均衡、数据库读写分离、分库分表等技术，系统的一个整体的架构大概是这个样子的：这种架构，会有什么样的痛点呢？我总结了一下，系统在不断发展的过程中，可能会遇到下面几种情况：数据到处都有：举个最简单的例子，如果一个公司对外的系统很多，每个系统都提供用户注册的功能，注册后用户信息保存到自己的系统，当公司内这样的系统越来越多，问题就会凸显；代码到处拷贝：如果数据库统一了，用户信息都存储到一个数据库中，开放给各个业务系统操作（事实上几乎没有公司会这样做），这样带来的一个问题就是，相同逻辑的代码，会分布在多个系统中；更严重的是，代码与数据库的耦合度太高，不易于扩展，
代码质量无法保证，系统之间相互影响:如果系统A写SQL，导致全表扫描，数据库的CPU飙升到100%或者导致表锁，影响的不仅仅是一个系统。这时候对用户数据的操作会被认为是代码层面的服务；服务后的架构大概是这样的(这里先不讨论是直接调用还是服务注册发现):服务的过程其实很简单。举个例子，说白了就是把用户相关的功能做成一个单独的系统，通过接口暴露用户信息的操作。那么服务的好处是什么，解决了什么问题？我总结了以下几点:统一的数据存储和集中的业务逻辑；调用者非常方便，一个函数只需要调用一个接口；如果是用RPC实现，就跟调用本地方法一样；调用者不需要关心具体的业务逻辑是如何实现的；掩盖了底层的复杂性:缓存是否使用，数据库是否需要划分为数据库和表，对于调用者来说是一个黑匣子；业务逻辑集中意味着只有一个代码，所以效率和稳定性可以得到保证；当数据汇集到一起，就可以进行下一步的处理、分析和预测，数据的价值就可以发挥出来了。当然，服务有利也有弊。比如用户中心挂了，会影响到所有依赖用户中心的系统(高可能性的要求很高)。
