Java开发微服务入门：微服务认知

翻译：叩丁狼教育吴嘉俊 

1. 介绍

微服务，当今业界最热门的话题之一，bulingbuling的，每个人，每个公司都想做，但有多少是真正从公司的人和组织结构角度去思考微服务会带来的变革。

这篇文章中，我们会从核心的原理，到准备实际操作的这个流程来讨论微服务架构。但是，这是一个每天都发生着大量创新的领域，所以，在这篇文章中将要讨论的所有内容，都是现在发生的实践，这些实践，是否在未来还有用，我们需要谨慎的去看待。无论好坏，业界仍在围绕开发和操作微服务不断的在实践中前进。

虽然对于如何正确的实施微服务有非常多的方法方式，但是真相却是：没有一条真正统一，有效的路让你万无一失。微服务化是持续学习和改进的过程，同时又需要尽可能控制住系统复杂度。不要把本文中所讨论的问题和答案看做理所当然，请保持开放的心态，并对新的挑战做好应对即可。

2. 我们身边的单块应用（monolith）

曾几何时，传统的单层架构和C/S架构（薄客户端/富服务端）是搭建所有应用和平台的首选方案。公平的说，对于大部分的应用，他们确实工作的很好（并且现在仍然工作的很好），但是突然有一天，微服务架构出现了，瞬间给所有的这些架构贴上了可怕的标签，许多人将他们视为老古董。

围绕技术的过度宣传会扰乱基本的常识，微服务就是一个典型的例子。单块应用并没有什么问题，并且目前仍然有不少成功的单块应用在正常的运行着。然后，确实单块应用会有一些限制需要我们去改进，我们就从单块应用的几个核心问题作为入手点，来看看为什么会选择采用微服务架构。

不管你是否认可，在很多公司里面，单块应用就是一个庞然大物。维护费用非常高，大量的bug增加了回归测试次数，降低产品质量，同时，新需求又需要耗费时间开发，导致整体项目难以按时交付。这就是一个很好的时机，回过头分析到底什么地方出了问题，应该怎么改进。在大多数情况下，把独立的代码库，直接分解成一组相对独立的模块或者组件，通过建立适当的API（不必改变模型打包方式），可能是最简单和最便宜的解决方案。

但是，你经常会遇到可伸缩性问题，包括软件平台的伸缩和工程组织的伸缩性，在面对单块应用架构的时候，非常难以解决。对于这点，经典的康威法则(Conway’s law)总结的非常到位。

“设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构” –