目 录
前言：
单体架构
SOA架构
微服务架构
前言：
随着近年来云技术的发展，越来越多的用户选择使用云技术来代替传统的IT基础设施。在云技术发展的早期，业界的关注点集中在虚拟化、分布式、存储等laas方面的技术。但随着“云原生”概念的提出，大家的注意力开始转移到如何构建更加合适环境运行的应用上来。
“什么样的架构才是适合在云环境中运行”是一个非常大的问题，在此先不展开讨论，而是到CNCF对云原生的定义中寻找答案：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网络、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统，结合可靠的自动化手段，云原生技术使工程师能够轻松地系统作出频繁和可预测的重大变更。
从上文的定义中可以发现“微服务”在云原生技术中占有非常重要的位置。在Jakarta.ee 2019年的调研报告中也印证了这一点，超过40%公司选择采用微服务架构来构件云上系统
在Java语言下，Pivoal强大的标准制定能力与影响力，Spring Cloud拥有一个强大的国际化社区，阿里巴巴作为整个社区里面的重要成员，也贡献出Spring Cloud Alibaba这套优秀的实现，这也是目前整个Spring Cloud体系下最完善并且在持续更新的实现方案。
需要掌握的知识点：
- 微服务的发展历程
- 微服务的基本形式
- Spring、Spring Boot、Spring Cloud的职责与关系
- Spring Cloud Alibaba的功能与定位
- Java工程脚手架的使用方法
- 沙箱环境的使用方法
概念：
通常业界所说的，没有最好的架构，只有最合适的架构。微服务架构也是随着信息产业的发展而出现的最有普遍适用性的一套架构模式。通常来说，架构的发展历程分为以下几种：单体架构、SOA面向服务架构、微服务架构
单体架构
很久以前，计算机发展的早期，创建的绝大部分的应用都属于单体应用，通常一个应用分为数据库连接、业务逻辑处理、展示逻辑等放到了一起，甚至于处理用户请求的地方也直接连接数据库。
后来，学习使用了MVC的架构，由此开启了应用的拆分之旅，多层架构的本质，是按照技术职责将应用做水平拆分，每一层解决的技术问题相对集中，层与层之间做单向依赖。可以更好的管理代码，大大提升了后期的维护效率，但是此时还是单体应用，部署也是按照一个整体运行。
优点有以下几点：开发简单、开发迅速、部署简单但是随着业务的越来越多，导致的应用的规模越来越大，逻辑越来越复杂，导致的这个应用也越来越难以维护。于是出现了SOA。面向服务的架构
SOA架构
SOA是Service-Oriented Architecture的简写，面向服务的架构，从名称来看是服务是SOA架构中非常重要的概念。SOA的核心思想是将系统的功能分为一系列的服务。
面向服务的架构SOA是一个组件模型，将应用的不同功能单元（称服务）进行拆分，并通过这些服务之间定义好的接口和协议联系起来。接口是采用中立的方式定义的，独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以统一的方式进行交互
与单体架构不同的是SOA是粗粒度的拆分，具体的标准参考康威定理，应用从单体应用做了垂直拆分之后，就会变成一些相对独立的应用。此时，应用之间的依赖、调用等相关问题。
相关协议的介绍：
- xml一种标记语言，用于以文档格式描述消息中的数据
- SOAP（Simple Object Access Protocal），在计算机网络上交换基于xml的消息协议，通常是HTTP
- WSDL（Web Services Description Language ，Web服务描述语言）基于xml的描述语言，用于描述与服务交互所需的服务的公共接口，协议绑定，消息格式
- UDDI（Universal Description ,Discovery .and Integration，是统一描述、发现与集成）基于xml的注册协议，用于发布WSDL并允许第三方发现这些服务
- ESB（Enterprise Service Bus，企业服务总线）--支持异构环境中的服务，消息以及基于事件的交互，并且具有服务级别和管理性
编辑
但是存在以下的缺点：高门槛，需要不同的协议以及厂家不同参与的，很多服务可能导致通信的协议无法进行统一；不适合云环境，不同的协议导致的上线以及集成都不一致导致的部署通信的问题；中心化，虽然实现了水平的扩展，但是ESB却成了系统的中心
微服务架构
编辑
微服务具有以下几种特点：
- 一套小服务
- 独立进程
- 轻量级通信协议
- 可独立部署
- 多语言不同存储技术
微服务可以说是一个庞大且复杂的概念集合，它既是一种架构模式，也是实现这种架构模式所使用的技术方案集合
需要解决的问题：
- 分布式的使用难点：原本在单体应用中，很多简单的问题都会在分布式环境下呗几何级的放大，例如分布式事务，分布式锁、远程调用。
- 协调代价：一个项目有几十个应用，这些应用又是不同的团队开发的，导致协调这些应用是一个很难的事情
- 服务拆分需要很强的设计能力，如果拆分不合理会导致服务不能很好的实现高内聚低耦合的要求
