单体架构
将所有系统功能全部在一个系统中实现，称之为单体应用。部署时通常以WAR包或JAR包的方式存放至Web容器。随着业务的发展，功能的增加，单体项目会逐渐庞大而臃肿。早期采用单体应用架构是合理的解决方案，功能迭代和应用部署较简单，随着时间的推移，单体应用架构存在的问题逐渐显现。
存在问题
系统复杂性高
随着业务需求的变动，造成系统模块边界的变更，模块之间的依赖关系不清晰。单体应用中功能模块代码耦合度较高，一个需求的变动容易引发出关联功能模块和系统功能使用异常。
技术债务
随着时间推移、业务需求变更、团队人员更迭、已使用的系统功能难以进行更新和迭代，逐渐形成单体应用的技术债务。
部署效率低
随着时间推移、业务需求变更，造成代码增加或更新，项目重新构建和部署的复杂度会增加。全量部署的方式耗时长、影响范围大、风险高，使得单体应用上线部署频率较低，多个单应用系统间接口调用出错概率高。
可靠性差
某个单应用系统出现功能缺陷，或多个单应用系统间接口调用出现参数调整或功能变动，容易影响整个单系统应用的崩溃。
扩展能力受阻
单应用系统只能作为一个应用系统整体进行扩展，无法构建为高可用、可伸缩式系统，只能通过硬件的升级对系统性能进行扩展。
阻碍技术创新
单体应用往往使用统一的技术平台或解决方案解决所有的问题，团队中的成员必须使用统一的技术体系。统一的技术体系在单体应用中可以应对研发任务，从系统高可用、可伸缩角度考虑，引入新的技术体系会相对困难。
解决方案
在对单体应用架构调整为分布式微服务架构的过程中需要注意如下问题
最小修改
在单体应用架构使用过程中，对于新需求的功能迭代，不应继续在继续增加原单体应用架构复杂度及系统耦合度，将研发工作重心转移到使用微服务的方式对新需求进行功能迭代。
功能分解
为当前单体应用系统功能，提供功能服务接口，对单体应用系统核心功能进行分解。使用代理机制，将系统用户对单体应用的访问转发至分布式微服务系统中，对系统用户与单体应用系统的使用依赖进行解耦。
数据解耦
随着部分功能的解耦，已经存在微服务功能模块为用户独立提供功能服务这时需要考虑数据解耦。从原有的单体应用数据库中剥离出相关功能模块对应的业务数据，尽量满足于每个微服务功能模块有独立的、隔离的业务数据系统。
数据同步
出于时间成本和技术曲线考虑，无法将一个复杂的单体应用统一改造为分布式微服务架构。在很长的一段时间内，对单体应用系统进行功能抽离逐渐形成新的服务功能模块(业务数据、逻辑)，导致无法与现有单体应用系统协作使用。为了保持持续交付，通常会在微服务功能模块和单体应用系统间使用ETL、消息中间件、访问单体应用系统数据同步功能服务接口（Restful）,对微服务功能模块与单体应用之间进行数据同步，保证未进行服务功能抽离的单体应用继续使用以及单体应用系统与微服务功能模块之间的协同工作。
迭代替换
通过对上述闭环过程的不断迭代，逐步将单体应用复杂系统功能拆分为独立的服务功能模块（独立的业务逻辑、业务数据），最终将单体应用系统替换为分布式微服务架构的独立服务系统
微服务
概述
微服务架构是一种将单体系统应用程序迭代为一组小型的服务方法，每个服务运行在自己的系统进程中，服务间采用通常轻量级通信机制（通常用http外部访问资源API）。这些服务模块围绕系统业务能力构建并可通过全自动部署机制独立部署。这些服务通过集中式管理维护服务间的协作关系。可以使用不同的技术体系、存储技术对业务功能提供服务。
微服务架构优点
易于开发和维护
一个服务模块只会关注拆分后的特定业务功能。业务清晰、易于对单个服务模块进行开发和维护。整体应用是由若干特定服务模块构建而成、协同工作，整体应用维持可控状态。
部署效率高
在单体应用中，一个功能的修改，就需要对单体应用整体重新部署。微服务根据业务将系统功能拆分为独立提供服务的模块，不会因为一个服务模块的功能修改导致整体应用重新部署，也不会因为一个服务模块的功能缺陷导致其它服务模块及整体应用不可用。
技术栈不受限
在微服务架构体系中，可以根据项目业务及团队特点，合理对技术栈进行选择。
高可用可伸缩
可根据业务要求，实现细粒度扩展。
微服务架构挑战
微服务在系统可用性、伸缩性上提供了优点，随着微服务技术栈的引进，也带来了需要面临的挑战。
运维复杂度提升
随着对单体应用系统不断进行服务剥离，递增形成了更多的独立服务模块。在单体应用系统中，只需要保证单体应用系统正常运行；在微服务架构中，需要保证更多的独立服务模块正常运行与协作，增加了系统运维复杂度。
分布式系统复杂性
使用微服务构建分布式服务系统，需要考虑系统容错、网络延迟、分布式事务、数据同步与一致、全局唯一标识等问题。
接口调整成本
独立的微服务模块间通过外部访问资源API进行通信，如果对API对应接口参数或功能进行了调整，通过外部访问资源API访问该接口的所有服务模块都要进行调整。
重复代码
在引进微服务架构的过程中，需要逐步对单体应用系统进行服务剥离，需要独立的服务模块和单体应用系统协作完成某个业务。在使用统一的技术栈进行微服务开发时不存在这样的问题，使用不同的技术栈提供独立服务模块时，需要对同样的业务需求提供不同技术栈实现。
设计原则
单一职责原则
每一个服务模块只需要关注整体应用中业务功能独立、系统边界明确的组成部分。
服务自治原则
每个服务模块具备独立的业务处理能力、服务测试能力、服务构建能力、服务部署能力。
轻量级通信机制
服务模块间通过轻量级通信机制进行交互。微服务架构中，常用的通信协议有REST、AMQP、STOMP、MQTT等。
微服务粒度
微服务拆分粒度是微服务难度。应当使用合理的粒度对服务进行拆分，而不是一味的把服务做小。
技术选型
开发框架选择
Dubbo更关注于服务调用、流量分发、流量监控、熔断；SpringCloud关注微服务架构生态发展。
运行平台选择
可以将微服务部署在PC Server上，也可以部署在阿里云、AWS等云计算平台上。
参考文献
https://www.cnblogs.com/cim3221847/p/6129435.html
https://mp.weixin.qq.com/s/aYlHAXNbwiXq7DPFOYTK6A?
参考书籍
| 书名 | ISBN |
| SpringCloud与Docker微服务架构实战第二版 | 978-7-121-34015-4 |
| SpringCloud微服务全栈技术与案例解析 | 978-7-111-60155-5 |
| 重新定义SpringCloud实战 | 978-7-111-60939-1 |
| SpringCloud微服务架构进阶 | 978-7-111-60868-4 |
| Spring微服务实战 | 978-7-115-48118-4 |
| 高可用可伸缩微服务架构 | 978-7-121-36213-2 |
