Java系统的服务化设计

蘑菇街

前言

当一个系统足够复杂以后，就会出现难以维护、难以开发、难以运维等等问题，服务化就是为了解决这个问题而出现的一种设计思路。通过将复杂应用拆分成独立的小应用，不同应用之间通过API交互，以保证各个独立应用的功能集中、逻辑清晰、业务聚焦，从而实现简单开发、简单运维。

实现思路

一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。每个服务如果有QPS压力了也可以很方便的水平扩展，只要不是类似于数据库层面的单点瓶颈，都可以通过加机器解决问题，虽粗暴却实用。
这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。

优势

首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。
第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。[1]

新的挑战

将复杂系统拆分后，各个系统内部是简单了，但是由于多了系统间的交互，就会带来新的问题。以阿里为例，类似阿里这样的复杂系统，拆分出的服务可能成千上万，那么久而久之，如何管理这成千上万个服务之间的相互依赖关系，如何保障高可用性就会越来越棘手。
这也是在越来越多的互联网公司中出现服务化框架的原因，伴随着系统的发展，必然需要出现这样一个东西来解决各种通用型的问题，比如远程服务调用，负载均衡、限流、跨语言等。