单块应用
单块应用流程
单体应用的开发，会在intellij idea/eclipse建一个工程，使用spring mvc+spring+mybatis整合，里面controller、service、dao、mapper、sql代码，加一大堆的配置文件，还会根据需要引入一些redis、elasticsearch、mq之类的依赖。
部署的时候，使用maven插件，把工程里的所有代码和依赖打包成一个jar包/war包，里面包含所有代码、依赖和配置文件
公司提供给你一台linux服务器，虚拟机/物理机，在机器上你自己先部署了一个tomcat，然后把你写好的系统的jar包/war包放到tomcat指定目录下去，然后重启一下tomcat，tomcat一旦启动就会监听类似于8080的端口号
然后你针对8080 端口号发起http请求，请求会由tomcat直接转交给你的spring mvc，一层一层调用你写的代码。这就是一个非常典型的单块应用开发。
单块系统开发的一些痛点.png
单块应用的问题
- 很多人维护一个单块应用，频繁的进行代码合并，频繁的解决代码冲突，解决冲突的时间和成本很高的，导致开发效率低下
- 每次上线都要跟最新代码进行合并，重新进行全量功能的回归测试，很多代码都可能给有变动，必须全量回归测试，耗费时间很多，开发效率低下
- 多人频繁上线，你等我，我等你，互相协调困难，而且可能会出现别人多次先上线，你多次重复的合并代码，解决冲突，全量回归测试，做很多次重复的事情，导致效率低下
- 测试服务器都很少，就一台测试服务器，你开发好了代码，你连测试都不能测，必须等待别人的分支先测试完毕上线，你才能去合并代码，解决冲突，等到一个测试环境可以用，回归测试
- 10个人以内维护一个单块应用，基本这些成本还不算太大，但是一旦10人以上维护一个单块应用，上述的成本会极大，导致系统每个需求的测试和上线，都非常缓慢，要耗费大量时间做全量回归测试，上线日期还得互相配合互相等待互相协调，一个疏忽，就可能导致没侧测试完全的代码上线出线上事故
- 如果你想要升级技术架构，不能随意升级，因为可能影响别人，你得让所有人都学习这个新技术架构才行；如果你想要升级已有技术的版本，不能随意升级，因为可能新版本对你的代码没影响，但是对别人的代码有影响
10人以内单块应用基本都问题不大，但是一旦10人以上，往往维护一个单块应用就比较麻烦了，通常建议的比较合理的是5人以内的小团队负责维护一个系统，针对这个问题，就需要使用微服务架构，把大系统拆分为很多小系统，几个人负责一个服务
这样每个服务独立开发、测试和上线，代码冲突少了，每次上线就回归测试自己的一个服务即可，测试速度快了；上线是独立的，只要向后兼容接口就行了，不需要跟别人等待和协调；技术架构和技术版本的升级，几个人ok就行，成本降低，更加灵活了
微服务架构相关背景介绍
假设把一个多人维护的单块应用拆分成多个服务（A-F），每个服务由几个人负责维护。
服务之间会进行通信，互相调用，但也会引发出很多问题，微服务为了解决这些问题，产生了很多组件，这些组件构成了微服务架构。
注册中心
如果服务A想调用服务B，就需要知道服务B的地址，又不能在服务A中写死服务B的地址，所以首先必须有个注册中心。注册中心可以让每一个服务都在服务中心注册，上传自己服务的地址，其他服务通过注册中心发现服务地址。
RPC框架
服务A和服务B部署在不同的服务器上，为了可以调用远程服务，服务A需要基于RPC框架去远程调用服务B
多环境隔离
多环境隔离是对于远程调用来说的，服务A和服务B都部署在测试环境里，服务A只能访问测试环境里的服务B，不能访问生产环境里的服务B。
自动化部署
项目的自动化部署
分布式事务
不同于单块项目，微服务中每个服务都会有自己的数据库，一个用户请求可能对多个数据库操作，分布式事务保证事务的最终一致性。
限流/熔断/降级
多个服务调用，如果一个服务挂掉，可能引起服务雪崩，所以需要引入限流/熔断/降级机制。
配置中心
一般来说，单块系统也会用到配置中心，在微服务架构中，每个服务都有很多配置，如果这些配置每次修改都要修改他的配置文件再重新部署就太坑爹了，所以就需要这么一个配置中心，修改配置时直接在配置中心修改，由配置中心推送到服务上，服务就可以使用最新的配置了。
监控中心
服务很多，就需要对每个服务进行监控，还包括整个系统的业务指标，每台服务器的内存，磁盘，网络，I/O，负载
链路监控
每个请求串成了一个链路，需要对每一条链路进行监控，每个环节是否成功，耗时
日志中心
在单块系统中，日志可以直接写到本地磁盘，在微服务架构中，每个服务都写在自己本地磁盘中，看日志会非常麻烦，所以需要所有服务都把日志上传到日志中心，在日志中心可以进行检索
服务治理
服务治理包含上面说的很多东西，包括注册，发现，监控，链路，日志都可以算是服务治理的范畴之一，所有关于服务管控、管理都可以算是服务治理。
API网关
现在架构基本上是前后端分离，用户通过前端/客户端发送请求到后端，在前端/客户端和后端之间，可以增加API网关，屏蔽掉后端所有服务地址，避免用户调用不同的服务地址，前端/客户端直接调用一个固定地址，由API网关根据请求格式，将不同请求路由给不同地址。便于解耦。
安全认证
在API网关中，还可以进行安全认证，统一限流等等很多工作。
微服务技术架构.png
国内互联网大厂的微服务架构演进路线
几乎所有技术组件都是自研，国内最早的微服务架构几乎就是一些互联网大厂自研了一大堆的组件，来支撑拆分成N多服务的大型系统的运行和多人协作开发，包括系统的监控和维护，等等
注册中心、RPC框架、多环境隔离、自动化部署、分布式事务、限流/熔断/降级、配置中心、监控中心、链路监控、日志中心、API网关、安全认证、服务治理
后来在三五年之前，阿里开源的Dubbo比较流行，在国内基本上把系统拆分为微服务的一些大大小小的公司，RPC框架用的都是阿里开源的Dubbo，注册中心用ZooKeeper的居多，当时dubbo+zookeeper基本就是一个最原始的微服务技术架构的雏形
至于其他东西，不同的公司可能会找不同的开源项目，但是都没太统一的标准，而且很多公司干脆压根儿就不用其他组件
海外硅谷互联网大厂的微服务架构演进路线
国外互联网公司，其实也都是几个大公司自己自研，后来逐渐的有一个叫做netflix公司的微服务技术架构开源出来，在国外有很大的影响力，然后接着就被整合到了spring社区，变成了spring cloud项目，里面整合的是netflix等国外公司的微服务相关组件
早期的spring cloud微服务体系的组件，是以eureka、feign+ribbon、zuul、hystrix，用zipkin和sleuth做链路监控，config做配置中心，stream做消息中间件集成，contract做契约测试支持，当然gateway也可以做网关，consul也是一种注册中心，还有跟spring security配合的安全认证，跟k8s配合的容器支持
这些都是国外公司为主的开源项目，spring cloud打包集成在一起，在国外比较有市场，两三年前在国内也火了，大量公司都开始拥抱spring cloud，尤其是中小型公司，几乎都是用spring cloud
因此呈现的一个状态，就是大厂几乎都是自研，部分大厂是以阿里的dubbo为核心自研的，部分中小型公司还是以dubbo为核心，加上自己找一些开源项目，然后更大比重的中小型公司，就是spring cloud那套技术架构，Spring cloud除了没有监控中心、日志中心、和分布式事务以外，基本都全的，所以可以快速搭建一套微服务架构。
目前国内公司的主流微服务技术栈介绍
两三年前，因为阿里开源的dubbo曾经不怎么维护，然后加上spring cloud完善的技术栈冲击进来，所以大部分中小型公司都开始拥抱spring cloud，dubbo的使用比例下降很多，所以最近两三年，国内微服务这块，其实大公司是以纯自研/dubbo+自研为主的，中小公司是以全面拥抱spring cloud netflix技术栈为主的
但是最近一年多，情况产生了变化，因为阿里的dubbo重启活跃维护，同时阿里把自己的微服务技术栈融入进了spring cloud体系和标准，形成了一个spring cloud alibaba微服务技术组件，也就是以nacos（注册中心）、dubbo（RPC框架）、seata（分布式事务）、sentinal（限流/熔断/降级）、rocketmq等技术为核心的一套技术体系
注册中心：nacos -> eureka
RPC框架：dubbo -> feign+ribbon
分布式事务：seata -> 无
限流/熔断/降级：sentinel -> hystrix
API网关：无 -> zuul
spring cloud netflix微服务技术组件，开始更新的非常不活跃，netflix公司公开宣布他之前开源的一些微服务组件未来就不会怎么更新了，这就导致spring cloud netflix微服务技术组件的未来有点不太光明，相比之下，spring cloud alibaba微服务技术组件，活跃的更新，社区也重启，做的很好，宣讲，演讲，采访，开始比较活跃起来
所以最近一年其实很多公司也开始尝试用spring cloud alibaba的技术组件，再加上一些其他的开源组件，同时其他的开源组件里，其实国内前天互联网公司也开源了不少优秀的项目，比如说携程开源的配置中心apollo（spring cloud config），大众点评开源的链路监控CAT（zipkin、slueth），加上其他国外的优秀开源项目，比如Prometheus（监控），ELK（日志中心），Spring Cloud Gateway（网关），等等，可以组成一套全新的以国内开源技术为核心的微服务体系
中心公司开始进行分化，有部分公司还是spring cloud netflix为主的一套技术栈，有少部分公司开始尝试推行spring cloud alibaba技术栈+国内开源的组件（apollo、CAT）+ Prometheus + ELK + Spring Cloud Gateway（Nginx+lua、Kong、Zuul、API网关自研）
我个人倾向于以及比较认可的，是这套技术体系，也认为会是未来国内的主流，因为netflix很多组件维护的都不够活跃了，所以衰退是必然的，加上国内的开源项目，都是中文文档，中文社区，交流也方便，也很活跃，所以学习是以这套国内为主的微服务技术体系为主的，也是面向未来的一套技术体系
网友评论