低调的牛肉
其实所谓的服务化并不是说一定搞微服务或者云服务，微服务只是一种架构思维，而是一个目前大部分软件公司在做的概念:“SaaS”，意思是软件即服务。
简单点说，就是软件开发商并不是卖软件，而是卖软件从开发实施到后期运行维护的一整套服务，作为客户的传统公司可以不需要雇佣数量大的IT人员就可以享受自己的企业转向数字化管理。这就是SaaS，软件不再是卖出去就结束，而是一直卖服务。
当然，服务化从技术层面上可以走微服务，毕竟传统架构已经满足不了分布式和高复用性的需求。
合作便是双赢
这种方式最大的好处是作为卖服务的软件供应商，可以持续不断得进行交付，进行收款，盈利比较持续稳定。
对于买服务的企业 可以把重心放在自己企业的核心业务上，不用花过多精力去招聘研发等IT人员去开发维护系统，这也给很多传统企业数字化转型提供了非常大的帮助。
因此SaaS算是一种双赢的存在，也是目前很多软件公司正在做的事情。
但是实际上，很多企业的SaaS之路并不顺利，都在产品化的路上渐行渐远然后不断跌倒爬起。
关注“极客宇文氏”，一名有料的软件工程师。极客宇文氏
首先要表明一个观点：脱离业务实际情况的架构都是耍流氓，所以不是所有系统都必须服务化，也不要为了服务化而服务化。
在了解服务化的好处之前，让我们先看看传统的系统架构是什么样的，当了解传统架构的缺点之后，再去看看为什么要做服务化，就容易理解了。
在单体服务的时代，我们是一台应用服务器，后面挂一台数据库。当访问量增多的时候，会引入负载均衡、数据库读写分离、分库分表等技术，系统的一个整体的架构大概是这个样子的：
这种架构，会有什么样的痛点呢？我总结了一下，系统在不断发展的过程中，可能会遇到下面几种情况：
数据到处都有：举个最简单的例子，如果一个公司对外的系统很多，每个系统都提供用户注册的功能，注册后用户信息保存到自己的系统，当公司内这样的系统越来越多，问题就会凸显；
代码到处拷贝：如果数据库统一了，用户信息都存储到一个数据库中，开放给各个业务系统操作（事实上几乎没有公司会这样做），这样带来的一个问题就是，相同逻辑的代码，会分布在多个系统中；更严重的是，代码与数据库的耦合度太高，不易于扩展。
代码质量无法保障，系统之间相互影响：假如A系统写了SQL导致全表扫描，数据库的CPU飙到100%或造成锁表，那么影响的不只是一个系统。
这时候会考虑在代码这个级别，对用户数据的操作，进行服务化；服务化后的架构大概是这个样子（这里先不讨论是直接调用，还是服务注册、发现）：
这个服务化的过程其实也非常简单，在例子中，说白了就是把用户相关的功能单独做一个系统，并且把对用户信息的操作通过接口的方式暴露出来，那么服务化有什么好处，到底解决了哪些问题呢？我总结有这么几点：
数据统一存储，业务逻辑集中；
调用方很方便，一个功能，只需要调用一个接口；如果是RPC的方式实现，就像调用本地的一个方法一样；具体业务逻辑是如何实现的，调用方不需要关心；
屏蔽了底层复杂度：用不用缓存，数据库是否需要分库分表，对调用方来说，都是黑盒；
业务逻辑集中，意味着代码只有这么一份，那么效率和稳定性才有可能得到保证；
当数据被集中在了一起，才能做下一步的处理、分析、预测，才能发挥出数据的价值；
当然，服务化有好处也有坏处，就比如..如果用户中心挂了，那么会影响到所有依赖于用户中心的系统（高可能的要求非常高）。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
先简单说下从传统的系统模式到服务化的演进。最早开发一个系统是单体的应用，也就是不管你的系统有多么复杂，功能有多么庞大，我们只会开发一个独立应用。但慢慢发现当系统开发团队逐渐变大，系统需求不断增加和变化时，这种方法不论是在项目管理还是在后期扩展和运维时都会带来很多麻烦。比如开发时不同模块的开发人员如何协作，需求变更带来的代码臃肿和晦涩，运维时一个小修改可能带来重启的巨大风险等等。
后来架构设计师们就在考虑业务拆分和系统拆分。这就是最初服务化的原型。最直接的拆分肯定是模块的拆分。但是拆分后的系统肯定需要相互依赖和调用，所以就延展出了一些接口技术，如Web Service，Restful。但这又进一步带来了新的问题，由于不同模块可能部署在不用服务器上，如果服务器或网络出现问题，可能使相互依赖的系统无法访问，最终造成雪崩效应，服务彻底瘫痪。
这时SOA架构产生，最早的ESB，后来的分布式，微服务都是慢慢衍生出来的系统架构。首先它进一步拓展了服务化的理念将业务进一步拆分成更小的服务单元，以避免单服务出现问题可能造成的瘫痪风险。其次由于服务分拆的较细，如何进行服务治理，发现注册服务、解决服务单点故障便成为分布式架构要解决的首要问题。紧接着服务熔断机制、服务配置中心、服务网关路由、服务消息总线以及服务日志跟踪等问题逐一得到解决。这也使得整个服务架构更加优化和完善，分布式系统已发展成熟并自成体系。
最后说明一下不管是服务化、SOA、分布式，这些系统架构一定不要因为流行而使用，如何使用，使用哪些和使用程度都要取决于你的需求、受众、使用场景等一系列因素。再好的技术也要用到正确的地方才会发挥更大的作用。
JAVA油腻男
就这么说吧，第一，你一个微服务挂掉了，对整个系统影响比较小。第二，开发的时候，一个人可以单独负责一个服务。 这是非常明显的两个优点，在应对非常复杂的业务的时候，非常适合。所以这种架构适合很庞大的一个系统，当你业务很简单的时候，就根本不需要考虑那么多东西了。
