微服务架构
服务进化
服务进化总体分三个阶段：单体应用>SOA>微服务
-
所有功能全部打包在一起(war或jar包) -- all in one
好处：容易开发、测试、部署，适合项目初期是错
坏处：随着业务发展，项目越来越复杂，主要有以下问题，复杂性高(代码多)、可靠性差(局部问题可能会引发全局问题)、扩展受限(无法针对性扩展，如IO密集型或计算密集型)、持续部署困难(全部打包部署，风险高)、阻碍创新(单体应用一种技术解决所有问题，不易引入新技术，成本较高)等
-
对单体应用的改进，引入SOA面向服务架构，拆分系统，用服务的流程化来实现业务的灵活性。服务间需要某些方法进行连接，它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在操作系统进程，各个服务之间通过网络调用；但是还是需要用些方法来进行服务组合，有可能还是个单体应用。
-
微服务是SOA思想的一种具体实践
微服务架构=80%的SOA服务架构思想+100%的组件化架构思想
微服务介绍
微服务是一种架构风格，将单体应用划分为小型的服务单元
微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通讯(HTTP);这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署，并且服务的集中管理应该是最低限度，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。
特性
组件
-
服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
-
服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
-
服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
-
将本地化的配置信息(Properties、XML、YAML等形式)注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移，也是无状态特性。
-
微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下，让用户能够在统一的界面中使用系统。Spring Cloud就是一个集成框架。
-
记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
-
系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能监控等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。
优点
- 独立部署：不依赖其他服务，耦合性低，不用管其他服务的部署对自己的影响。
- 易于开发和维护：关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。
- 启动块：功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。
- 技术栈不受限：java，C++，php等
- 按需伸缩：某个服务受限，可以按需增加内存，cpu等。
- 职责专一：专门团队负责专门业务，有利于团队分工。
- 代码复用：不需要重复写。底层实现通过接口方式提供。
- 便于团队协作：每个团队只需要提供API就行，定义好API后，可以并行开发。
缺点
-
分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂。
-
分布式事务的挑战：每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。目前最理想解决方案是：柔性事务的最终一致性(遵循BASE理论)。
-
接口调整成本高：改一个接口，调用方都要改。
-
测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API文档的管理也尤为重要(yapi)。
-
运维要求高：需要维护几十或上百个服务，监控变的复杂；并且还要关注多个集群，不像原来单体，一个应用正常运行即可。
微服务技术选型
Spring Cloud和dubbo组件比较
dubbo：zookeeper+dubbo+springmvc/springboot
通信方式：rpc
注册中心：zookeeper，nacos
配置中心：diamond（淘宝开发）
spring cloud：spring+Netflix
通信方式：http restful
注册中心：eureka，consul，nacos
配置中心：config
断路器：hystrix
网关：zuul，gateway
分布式追踪系统：sleuth+zipkin
| dubbo | spring cloud | ||
|---|---|---|---|
| 背景 | 国内影响大 | 国外影响大 | 平手 |
| 社区活跃度 | 低(现在又好了) | 高 | cloud胜出 |
| 架构完整度 | 不完善（dubbo有些不提供，需要用第三方，它只关注服务治理） | 比较完善，微服务组件应有尽有。 | cloud胜出 |
| 学习成本 | dubbo需要配套学习 | 无缝spring | cloud胜出 |
| 性能 | 高（基于Netty） | 低（基于http，每次都要创建） 此性能的损耗对大部分应用是可以接受的。而HTTP风格的API,是很方便的。用小的性能损耗换来了方便。 |
dubbo胜出 |
系统架构
常见架构图：
基于Spring Cloud技术栈的架构图：
备注：世界上没有完美架构，只要满足业务需要“比之前好一点” 或者 “目前是最好的实现方式”就是一个好的架构。
