F1V3.0-1 单体应用的硬伤及解决之道

1 单体应用的硬伤

在过去很长一段时间内，开发的应用都属于单体式应用，这类应用易于调试和部署，而且通过在负载均衡器后端运行多个拷贝可以轻松实现应用扩展。不幸的是，这类应用有很大的局限性。

1.1 庞大、扩展运维困难

一个简单的应用会随着时间推移逐渐变大。随着功能逐渐增多，一个简单的应用逐步变成了一个巨大的怪物。一旦应用变得又大又复杂，开发团队肯定很痛苦。敏捷开发和部署举步维艰，由于应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。

1.2 开发效率低

单体式应用也会降低开发速度。应用越大，启动时间会越长。如果开发者需要经常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。

1.3 资源冲突严重

单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块完成一个CPU敏感逻辑，而另外一个模块为内存敏感逻辑。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。

1.4 可靠性差

单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。

2 解决之道

怎么解决这些问题呢？
通过采用微服务架构能较好的解决这些问题。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务一般完成某个特定的功能，每一个微服务都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用，一些微服务完成一个Web UI。运行时，每一个实例可能是一个云主机或者是Docker容器。

1、复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

2、独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

3、技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。

4、容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

5、扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

6、功能特定：一个微服务一般完成某个特定的功能，比如消息管理、客户管理等等。每一个微服务都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。
关于微服务的架构设计的内容可以参看一篇文章微服务架构设计

3 应用微服务的挑战

微服务架构不是银弹，在解决了单体应用问题的同时也带来了其他挑战，主要有：
1.固有的复杂性：微服务架构有很多优点，当然也有其不足。比如微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。

2.分区的数据库架构：另外一个关于微服务的挑战来自于分区的数据库架构。在商业交易系统中同时给多个业务分主体更新消息很普遍。这种交易对于单个应用来说很容易，因为只有一个数据库。而在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

3.波及多个服务：最后一个问题在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个项目案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单个应用中，你只需要改变相关模块，整合变化，部署就好了。相比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

4 选择微服务吗

微服务解决了单体应用的硬伤，但同时又带来了其固有的调整，那我们需要选择微服务吗?
微服务比较适合未来有一定的扩展复杂度，且有 很大用户增量预期的应用
对于大的互联网公司，用户量巨大，功能不断扩展，微服务架构自然是最好的选择。
对于一般的公司而言，实践微服务有非常大的技术挑战。如果应用未来有较大的发展，微服务也是一个很好的选择。如果应用已经比较成熟，而且看不到很大的扩展，则没必要为了微服务而微服务。
对于新启动的云应用，微服务架构应是不二之选，因为它让你既利用了横向扩展架构，也利用了纵向扩展架构，还额外得到API的组合，且在整个业务中可重复利用。可能在每一分钟都在交付新服务，这样你就会拥有一个敏捷的且即时响应的应用程序平台
参考微服务（Microservice）那点事