什么是微服务

微服务应用是与单体应用区分开来的.
当一个单体项目随着业务的发展会越来越膨胀,变得更加难维护,从一开始仅需一两个人到需要两三个团队,多个团队维护同一个项目无疑是一场灾难,沟通成本大大增加,技术协同也会十分困难.
举个例子,我在上一家公司维护过一个后台项目,它是一个公共后台,全司上下各个团队都可能用它来看数据,都来维护它.面对这样一个项目,明明我只需要维护十几个类,但每次我都需要在几百上千个类中找到它们.一些配置项,公用组件我想改却改不了,因为就算我的部分测试通过,也不能保证以后在其他业务会不会产生新的问题,而且出了问题有时很难追踪是谁的责任.
单体项目膨胀到一定程度后,就需要拆分了.微服务本质上就是对单体应用的解耦,拆分,从业务,功能上抽象成若干个模块.代码上解耦/独立只是第一步,根据实际需求,微服务架构也可能需要做到数据库独立,团队独立等.

为什么需要微服务

如上,微服务的出现是为了解决单体架构带来的问题.这里再敞开具体聊聊.

复杂性逐渐变高
比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
技术债务逐渐上升
公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
部署速度逐渐变慢
这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。
阻碍技术创新
比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。
无法按需伸缩
比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

那么微服务应该怎么学习呢，这里分享一份使用微服务的最佳实践。以贯穿整书的示例为出发点，由浅入深地阐述使用微服务的最佳实践，以及如何避免采用微服务架构可能带来的复杂性陷阱。

第1章会介绍微服务架构的整体概念，其中包括对微服务的基本定义。之后会快速浏览本书中所使用的样例程序。

第2章将阐明定义微服务组件的指导原则，并说明这些组件如何成为微服务架构的核心支柱。我们会通过Spring Boot 框架的Java 项目来有效地定义微服务组件，进而解释这些指导原则如何在实际中使用。最后，通过- -个微服务样例来实际演示基于Java的微服务组件如何进行配置和服务发现。