什么是微服务？
在我们开始学习微服务之前，我们首先需要了解清楚什么是微服务。
多年以来，软件开发人员一直在寻找更好的办法来构建应用系统。他们在学习已有技术的基础上尝试新的技术，也目睹过其他新兴的技术公司使用不同的方式来构建IT应用系统，从而提高了客户满意度和开发效率。随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。
而微服务，简单地说就是一些协同工作的小型同时又自治的服务。
微服务 —— “微”即是小
一个软件系统随着新功能的增加，其代码库只会变得越来越大，时间久了代码库会变得非常庞大，以至于想要知道该在什么地方做修改都很困难。尽管在代码库中会做到清晰地模块化，但是这些模块之前的界限很难维护，相似的功能代码在代码库中随处可见，使得修复bug或实现更加困难。
在单块系统中，通常会创建一些抽象层或者模块来保证代码的内聚性，进而避免上述出现的问题，而对于微服务来说，内聚性这一概念也很重要。应用在微服务上简得来说就是需要根据业务的边界来确定服务的边界，这样子就很容易确定某个功能代码应该放在哪里。而且由于该服务专注于某个边界之内，因此可以很好地避免由于代码库过大衍生出的很多相关问题。
那既然因为代码库过大我们需要拆分成小的，那代码库多小才算小？一般的回答就是：足够小即可，不要过小。
在考虑多小才足够小的时候，应该考虑的因素为：服务越小，微服务架构的优点和缺点也越明显。使用的服务越小，独立性带来的好处就越多，但同时管理大量的服务难度也会越大越复杂。
微服务 —— 自治性
一个微服务即一个小服务其实就是一个独立的实体，它可以独立地部署在一个平台上，也可以作为一个操作系统进程存在。
每个微服务之间可以通过网络调用进行通信，这加强了服务之间的隔离性，避免紧耦合。
这些服务是可以彼此独立进行修改，且某一个服务的部署不应该引起该服务消费方的变动。对于一个服务来说，需要考虑的是什么应该暴露，什么应该隐藏。如果暴露得过多，那么服务的消费方会与改服务的内部实现产生耦合。这会使得服务和消费方之间产生额外的协调工作，从而减低服务的自治性。
微服务的主要好处
技术异构性：在一个由多个微服务相互协作组成的系统中，可以在不同的服务中使用最适合该服务的技术。如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分。
扩展性：一个单块服务只能作为一个整体进行扩展，即系统中只有一小部分存在性能问题也需要整个服务进行扩展。如果使用多个微服务，则可以只对需要扩展的服务进行扩展。
可组合性：在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，系统会开放很多接口供外部使用，当情况发生变化时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。
java与微服务
在讨论“Java与微服务”之前，应该先简单回顾下Java的软件系统架构史，通常会将微服务架构设计与单体架构设计风格进行比较。
单体应用：一个单体应用即是一个单独的系统，通常在被集成在一个WAR包里。一个完整的企业应用主要分为以下三个部分：客户端、数据库管理系统、服务端程序。服务端程序将负责处理HTTP请求、执行业务逻辑代码、从数据库获取数据或更新数据、选取HTML页面并返回给客户端。这样子的服务端程序便是一个典型的单体应用，该系统的任何改动需要生效的话，都需要对服务端程序进行新版本的构建和部署。
构建一个单体系统的常用方法是一个单体服务器。处理请求的所有业务逻辑代码运行在一个单独的进程里面，通过类、方法和包名来进行拆分。在开发电脑上运行并测试，然后通过部署流程确保变更修改被测试过后部署到生产环境，通过在负载均衡器后面部署多个实例来实现水平扩展。
最开始单体应用也是很好用，关注于代码的模块化设计、包的拆分等，但后来逐渐意识到它的一些问题：变更生效不够灵活——改变应用的一小部分时，需要将整个单体应用进行重新编译并部署，时间一长通常很难保证将应用保持良好的模块化结构，也使得对于一个模块的修改很可能会对其它模块产生影响。在进行扩展时需要对整个应用进行部署，实际上需要扩展的可能只是整个应用里面的部分模块，相对于仅部署部分模块而言耗费了更多的资源。
如果使用微服务架构设计风格：应用由一系列的服务进行构建，每个服务都可以独立部署和扩展，且每个服务仅负责它该负责的业务功能，甚至服务间的实现语言可以并不相同，这些服务甚至可以有多个不同的团队进行管理。这样子那些变更生效不灵活和重新部署等问题将变得不值一提，能够对系统进行更多更灵活的调整。
参考资料
《微服务设计》 【美】Sam Newman 著 崔力强 张骏 译 人民邮电出版社
『Java微服务实践』101. 微服务导读 作者：程序员精进 链接：https://www.jianshu.com/p/74a99c0c844d 来源：简书
网友评论