微服务是近期非常热门的话题，芸芸众生言必谈微服务。但是，在实践过程中，我们发现一些项目，貌似用着微服务的技术，但做出了非服务化的应用，非但没有达到目的，反而徒增了架构的复杂性，让人汗颜。因此，在微服务之前，有必要搞清楚什么是服务化。
1. 官僚不是服务化
河北省武邑县需要往返6次才能办一个护照，深圳小孩出生要跑社保局、街道办、派出所，这些都是服务化程度低的标志。官僚化的程度越高，服务化的程度就越低。买房子相对好些，在入伙的时候，水、电、煤气一站式搞定。
2. 烟囱不是服务化
最近一次出差，使用了 e系统、i系统、s系统 等好几个应用，经过长期的优化，这几个系统的体验都还算不错。但用起来总感觉怪怪的，问题在什么地方呢？很多时候，当你需要找一个想要的信息，比如航班信息时，你往往不知道要到那个系统去查。 e系统、i系统、s系统都是品牌和口碑很好的应用，但放在服务化场景下重新思考，我们很容易的发现：烟囱化的应用不是服务化。
3. 超链接不是服务化
既然烟囱不是服务化，那我用超链接把各个烟囱串联起来，是不是就是服务化了呢？显然不是，简单的超链接让事情变得更加糟糕，而不是更好了。超链接就如同单向的门，为了打通两个房间，我们需要安装两个单向的门，房间数更多的时候，门的数量也更多，最后组成了一个什么呢？对，一个迷宫。
服务化的系统，不是仅仅将相关功能连接在一起，而是有机的整合、简化成 One System，让基于当前场景的用户感觉可以流畅的处理端到端的业务，而不必到处在风格迥异的系统间跳转以致摸不着头脑。
4. REST 不一定是服务化
我做了一个应用，有前台，有后台，前台通过REST（或者SOAP、RPC等）调用后台，是不是就服务化了呢？其实不然，这个还可能是一个烟囱，一个伪装了的烟囱。
5. 单体应用不一定不是服务化
服务化（SOA）是一种构建分布式应用的方法，本质上是实现能力在分布式环境中的重用。单体应用通常跟微服务应用对立起来，单体应用并没有跟SOA对立起来，单体应用也一样可以暴露足够的服务供其他的分布式应用来使用（与烟囱的区别），从而实现服务化的重用。
另外，单体架构并不一定不是好的架构，这取决于应用的复杂度。一个初创的公司，要在互联网-上开展业务，由于业务规模不大，业务复杂性有限，码农数量也不多，这个时候，单体架构就是最合适的。即使对于华为这样的大型公司，在某些独立的领域，如果一个单体应用能很好的覆盖完整业务场景，单体架构仍然是合适的。
6. 组织结构服务化才能实现服务化。
俗话说，组织架构决定技术架构。有烟囱式的组织架构，很容易导致烟囱式的系统。要实现服务化，必须打破原先一个团队搞定一个烟囱的组织架构，变为一种服务化的组织架构。应用的前端和后台应该采用完全不同的设计方法，前台UI的设计是完全以用户为中心的，而后台的服务设计则是以业务为中心的。前台和后台最好归属到不同的团队，以避免他们造烟囱的强烈生理冲动。
7. 针对完整场景的才是好的服务化。
割裂的场景导致割裂的体验，好的服务化设计都是针对完整的场景的。让用户在端到端的场景中拥有完整的、一致的、简单的、明确的体验。什么是端到端完整的场景呢？
o 差旅就是一个完整的端到端场景，从出差申请，到机票预定、酒店预定、签证申请，再到出差报告、报销整个一条*LONG*服务。
o HIC也是一个完整的端到端场景，从应用注册，到应用开发、测试、资源申请、配置管理、持续集成、持续交付、运维自动化，整个链路覆盖。
如果割裂开来，针对部分场景设计一个应用，另外的场景设计另外一个应用，则很容易形成烟囱。即使只是针对完整场景中的任何一个遗漏，都会导致服务化体验的劣化。
8. 大型系统服务化的必然结果，是业务中台化。
前面提到过，前台UI的设计是完全以用户为中心的（我的任务、我的订单、我的合同），而后台的服务设计则是以业务为中心的（比如订单处理、合同处理、财务处理等）。用户通常希望一站式的体验，那如何将一站式的以用户为中心的前台和分散的以业务为中心的后台结合起来？答案是业务中台。业务中台承接前台的请求，并整合后端的服务，在这个过程中，可以进行特定的映射、整合、规则化处理、自动化处理、智能化处理，这里侧面印证了IT中台化战略，即前轻、中强、后稳的战略。
总体来说，服务化的目标，是通过更加服务化的组织和完整的服务化的实践，构建针对完整业务场景的一站式的ROADS用户体验（套用一句流行的话）、更加解耦的架构，从而实现全流程的在线处理、更高的业务作业效率，提升业务数字化转型效果。我们不能过度强调技术，而忽略体验，因此，理解什么是服务化比理解什么是微服务更加重要。
下篇，再讲讲我对微服务的理解，敬请关注。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
