1.单体应用与微服务架构区别
2.什么是微服务
自2014年起，微服务架构由Martin Fowler、Adrain Cockcroft、Neal Ford等人接力进行介绍、完善、演进、实践后，一直维持着较高的热度直到现在，内容如下：
微服务架构是一种架构模式，它提倡将原本独立的单体应用，拆分成多个小型服务。这些小型服务各自独立运行，服务与服务间的通信采用轻量级通信机制（一般是基于HTTP协议的RESTful API），达到互相协调、互相配合的目的。被拆分后的服务都围绕着具体的业务进行构建，每个服务都能独立地进行开发、部署、扩展。由于相互独立，且采用轻量级通信机制，各个小型服务也能够使用不同的语言开发，也可以使用不同的数据存储技术。
微服务是一套经过漫长的架构演进、良好架构设计的分布式架构方案。从传统单体应用到分布式独立应用，从应用数据服务到引入缓存优化性能，从反向代理和CDN加速网站响应等等，技术架构不断演进的过程中，逐步出现前后端分离，数据读写分离，云原生、DDD领域驱动，最终孵化出如SpringCloud、SpringCloud Alibaba等成熟稳定的微服务架构方案。
微服务其主要特征：
服务自治：团队独立、技术独立、数据独立、部署独立
面向服务：微服务对外暴露业务接口，如RESTful API调用
单一职责：每个应用领域边界清晰，功能职责单一，无重复工作
3.微服务优缺点
3.1 优点
①易于开发维护
微服务基于领域模型拆分的应用，其内部模型高度统一，功能相对内聚，开发人员只需要对固定模型进行领域业务接口封装即可。
②技术栈开放
微服务因独立部署、独立开发，因此开发团队可以根据资深团队特点进行技术选型。如团队擅长关系型数据库则MySQL，擅长图形计算则Neo4j。
③升级错误隔离
A技术专项升级因单独部署，不再影响整个分布式架构中全部功能，只影响有接口交互的部分应用，而这种应用也可以通过灰度、服务降级、服务熔断的方式兼容和处理，不会因一个错误导致整个应用瘫痪。
3.2 缺点
①运维成本高
更多的服务意味着更多的运维投入，传统应用中只有一个应用，而为服务中，需要保障几十、上百个服务的正常运行和协作。
②调用链路复杂
微服务架构中，不可避免的会出现A服务依赖B服务，B服务依赖C服务，C继续依赖D服务的场景，一旦A调用异常，排查链路可能会从A->B->C->D，才能最终发现服务报错具体信息（后续skywalking可解决）。
③分布式事务问题
同上例A->B->C->D的长链路调用过程中，如果A先修改自己数据，但下游C却异常，此时预期是A回滚自己事务，这一点在单体应用因都是本地事务可以很好做到，但是分布式场景下却提升了复杂度(后续Seata可解决)。
④学习成本高
微服务学习除了需要一定基础之外：Spring、SpringMvc、MyBatis、SpringBoot、Maven、MySQL等，还需学习SpringCloud，中间件、缓存、Docker、文件服务器等多种技术，每一门学习都有很多难点需要克服。
4.如何实现微服务架构
至此我们了解了微服务的定义、优缺点，还总结了一些指导性的原则，下面我们进一步探讨下，如何实现微服务架构。
4.1 技术选型
1.开发框架
可使用SpringCloud作为微服务开发框架，因为SpringCloud为微服务架构提供了完整的解决方案，同时文档丰富，社区活跃，如下：
当然借助于SpringBoot+Nacos+Dubbo等其他技术架构也可以实现微服务架构，但因SpringCloud丰富且完整的解决方案体系，作为新手学习笔者在此更推荐依此学习，此学习过程中涉及的理论在今后的工作中也一定大有帮助。
2.运行平台
微服务并不绑定运行平台，将微服务部署在PC server、阿里云、AWS等云计算平台都是可以的。出于轻量、灵活、应用支撑及现在市场主流部署模式，笔者选择Docker作为部署容器。
4.2 通用微服务技术架构图
物理部署图、技术架构图、业务架构图、领域模型图、E-R图各自是什么？如何画？请移步：链接
5.总结
本文介绍了微服务基本概念、演变过程，主要的原则及优缺点，最后谈到了微服务的实现方案之一，作为引文此章节偏理论知识一些。后续笔者将借助具体技术实现带领读者一起逐步实现微服务架构体系。
思考问题
什么是微服务？
什么是微服务架构？
微服务架构演进过程？
6.推荐阅读资料
领域驱动设计：软件核心复杂性应对之道.pdf
(59.1 MB)
大话设计模式.pdf
(69.6 MB)
