目录
1.什么是微服务2.单体应用架构
3.微服务架构
4.微服务架构技术栈
1.什么是微服务
马丁·福勒 ，他于2014年发表了一篇关于微服务的博客：
微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。
博客地址：https://martinfowler.com/microservices/；
微服务详细文档：https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
2.单体应用架构
一个应用中包含了应用程序的所有功能（比如：页面，代码，配置等），把应用打成一个war或jar包部署到Tomcat中，通常称为单体应用架构。
单体应用架构的优缺点：
单体应用架构的优点：
- 易于开发&测试：单个应用包含所有功能，不涉及多个应用的互联互调，便于在团队之间开发与测试。
- 易于部署：只需将单个应用打成war或jar包，进行部署到Tomcat即可，运维起来比较方便。
- 易于整体扩展：当应用负载压力大时，将这个应用复制几份，分别部署在不同的服务器上，再通过负载均衡即可提高应用的并发能力。
单体应用架构的缺点：
- 复杂性高：由于是单个应用，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
- 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
- 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
对单体应用架构的思索：
假设你要开发一个类似滴滴的打车应用。在单体应用的架构下，你可能这样设计：在架构核心，设计了乘客管理，司机管理。行程管理，支付，消息通知等核心模块。围绕核心模块，我们再设计各种接口适配器，如同数据库对接，同移动端的api接口，web页面，对其他外部组织对接接口等等。然后我们就可以打成一个包，进行部署。
对上述单体应用架构构建的项目，在早期没有太大问题。我们还可以通过负载均衡器在做多个实例的负载均衡。
然而，成功的应用有一个趋势，就是随着时间推移而变得越来越臃肿。首先，在业务快速发展的阶段，开发人员每天有大量业务变更需要开发，在996已经不能保证完成工作的情况下，还要开发人员保证应用架构的干净是有点强人所难的。在业务代码变得足够复杂之后，团队中很快就没有人能完全理清所有业务，只能负责自己的一小块。最终，正确修复bug和开发新功能都变得越来越困难，只能不断的打补丁。最终单体应用会变成一个无人可以理解的超大型乱码。
最后的结果是：你不要尝试去重构，就让他这样跑着吧。同时伴随而来的是，单体应用的部署时间越来越长。一个单体应用对服务器的要求也越来越高。
另外，单体应用还有一个问题是可靠性。因为所有模块都运行在同一进程中。任何模块的一个 bug，比如内存泄漏，可能会拖垮整个进程。此外，由于应用程序的所有实例都是相同的，该错误将影响到整个应用的可用性。
所以，一个成功的应用最终会变成只有少数人能维护的巨大单体。使用着陈旧的技术，很难找到合格的新开发人员。部署困难，重启耗时极长，可靠性也得不到保障。无法重构，或者重构的代价极大，必须同时重构整个单体。
3.微服务架构
对单体应用问题的探索，诞生了微服务架构。我们将核心业务的几大业务模块，拆分为独立的迷你应用。他们都有自己独立的核心逻辑和对外相互对接的接口。
每个迷你应用都对外暴露REST服务API。各后端服务可以相互调用。一些 REST API 也暴露给移动端应用使用。然而，前端应用不能直接访问后端服务。前端对后端的服务调用要通过API网关。API 网关统一负责负载均衡、缓存、访问控制、API 计量和监控。
微服务架构模式明显影响到了应用程序与数据库之间的关系，在单体应用中，所有业务共享一个数据库。然而现在，微服务建议其每一个服务都有自己的数据库。这样做的缺点是可能导致部分数据冗余。但是，从微服务架构的角度去理解，业务A的数据库本就不该存业务B的数据，所有的关于业务B的数据，从应该由业务B的微服务对外提供。
另外，在这种架构下，我们可以为业务选择合适的数据库。比如对某些业务，我们需要选择支持高效地理位置查询的数据库。
微服务的优缺点：
微服务的优点：
- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快。
- 局部修改容易部署：单一应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
- 按需伸缩：可根据需求，实现细粒度的扩展。
微服务的缺点：
- 运维要求高：更多的服务意味着要投入更多的运维。
- 分布式固有的复杂性：微服务本质上说还是一个分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
- 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
微服务架构总结：
- 微服务的核心就是将传统的单一应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事。
- 在 IDEA 工具中使用Maven构建的一个个独立的 Module ，也就是使用Spring Boot 开发的一个个小模块就是一个个微服务，将专业的事交给专业的模块来做。比如一个大型项目可能有上百个微服务，将这些微服务集中起来构成一个大的系统，对外暴露服务进行调用与使用。
- 从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
4.微服务架构技术栈
搭建分布式微服务架构的技术栈：
微服务技术维度 | 技术实现 |
服务开发 | Spring Boot、Spring、Spring MVC等 |
服务注册 | 与发现 Eureka、Zookeeper等 |
服务调用 | Rest、RPC等 |
服务熔断器 | Hystrix、Envoy等 |
负载均衡 | Ribbon、Nginx等 |
服务接口调用(客户端调用服务的简化工具) | Feign等 |
消息队列 | Kafka、ActiveMQ等 |
服务配置中心管理 | Spring Cloud Config等 |
服务路由 | （API网关） Zuul等 |
服务监控 | Zabbix、Nagios等 |
全链路追踪 | Zipkin，Brave等 |
服务部署 | Docker、OpenStack等 |
数据流处理 | Spring Cloud Stream（Redis,Rabbit,Kafka等发送接收消息） |
事件消息总线 | Spring Cloud Bus |
…… | …… |
