大佬指明方向！使用微服务的最佳实践以及如何避免采用微服务架构可能带来的复杂性陷阱

什么是微服务

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

为什么需要微服务

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

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

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

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

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