说到微服务
逃不过的两个前置和后置东西
单体应用和Serverless
微服务的出现是为了解决单体应用带来的问题
问题可以从4个角度去看待
- 1.功能角度
- 2.开发角度
- 3.测试角度
- 4.运维角度
功能角度：
单体应用是把多个业务模块合并在一个系统里面进行开发和迭代
这里面会带来一个问题
每次的构建和编译和特别耗时
会导致牵一发而动全身的情况
微服务虽然这两年比较流行，但是不是一个新的概念
比如在腾讯里面，所有的服务都是以微服务的形式存在
那它基本上就是c++编译为动态库
然后热加载
这样子去启动每一个rpc的服务
单体应用微服务化带来什么好处呢？
很明显，就是我们经常讲的：高内聚，低耦合
每一个服务的功能更加聚合了，
那么它能提供更加细粒度的接口或是rpc的功能
对于每一个微服务
它的每一次的构建跟编译会更加高效
开发的时候
不会影响到其他的业务模块
研发角度
每一次开发一个更细小的模块，更细小的服务
其实它的每一次的编译构建联通测试
他都会比较便捷，效率会更高
测试角度
每一个微服务它提供的功能是更加内聚的
每一个功能的点，粒度是更小的
对于测试同学来说
他们在写一些自动化脚本或工具的时候
会更容易去对接
同时对于微服务，它的上下文的逻辑
没有像单体应用那么复杂
对自动化测试来说，会比较标准
而标准呢
就是一些自动化的前提
运维角度
每一个服务的独立，运维在部署上线的时候
能够更小的影响业务面
比如说要有影响，最对就是影响这个模块的业务了
相比之后
单体应用每次部署的影响是影响整个实例里面所有的业务模块
所以微服务影响的是整个一套的研发流程
微服务化，所谓带来了很多好处，同时也引入了很多问题
上面是从4个角度讲它的优势，下面再从4个角度讲它的劣势
首先对研发同学来讲：
以前只需要去一个项目去研发
现在呢，一个大的系统会分为几十个微服务
这时候，对研发同学来讲，每一次在做新业务功能的时候
都要很麻烦的去找各个模块
从测试的角度来讲
测试在测试业务功能的时候，经常去跟踪功能，日志，数据
有了微服务之后
测试在进行整个的链路的时候，压测的时候
每一个环节都要去解决
每一个环节都要去更近
对于测试来说是一个额外的负担
从运维的角度来讲
以前发布一个单体应用
虽然每一次部署都会影响到某一个示例的完整的功能
但是现在微服务化了之后
他要去梳理整个服务之间调用的链路
去有一个依赖的关系
对于他来说是一个额外的负担
同时每一个服务的部署
以前部署的是单体应用
我们可以通过灰度发布来解决部署所带来的影响
但是现在部署呢
需要部署成几十上百服务
对于运维来讲，或是从成本上讲是不低的
同时微服务，所带来的问题，不仅仅刚才讲了各种角色身上的职责和任务的加重
它同时对系统的复杂性带来更大的挑战
首先从一个单体应用，演化为一个微服务的系统
面临的第一个问题就是，如何去做微服务化
也就是说如何去拆分服务，这里就见仁见智了
有的人可能把之前的一两个模块变成一个服务
也有人把它全部都拆开了
这里面拆服务的套路还是看他的对业务的理解和他的技术的积累
紧接着呢，微服务化之后会面临一个很重要的问题
以前单体应用的时候，对数据库的操作，我们可以有一些事务
但是微服务化了之后，各个服务之间是分离的
我们在有一些操作，比如下订单的流程
可能涉及到多个不同的业务去结合
我们是希望以事务的方式去做
但是微服务化之后呢
每一个独立的系统很难去做
也就是说，引入微服务之后呢
你要去解决事务这个问题
你要么选择分布式的事务
要么选择有限状态机
那这，也算他引入了额外的一些负担了
接着，我们在服务的请求过程中
我们需要去进行链路的追踪
对于之前的单体应用来说
可能就是在入口的时候
分配一个requestid
在每一个环节打日志的时候
把requestid写进去
现在分布式了微服务了之后呢
每一个实例的日志以及他的追踪
又面临了新的问题了
那么这个时候
就需要引入不同的日志采集服务了
虽然单体应用的时候也会用到
另外系统微服务化了之后呢
虽然给整个系统带来了很多额外的工作量
但是系统的每一个服务变的更加独立了
那么由此我们可以做更多对整个系统的稳定性，可用性的很多动作
比如说
熔断机制
那熔断机制这个概念呢是从金融体系，比如股票炒股的那个里面来得
当下游服务不可用
或是达到一个阈值的时候
我们可以控制对下游服务调用的频率
或是减少调用的次数
去尽量的保障和控制系统的可用性
那么目前行业对无服务的实现呢
主要有两种
- 第一种是基于7层http协议的 第二种是基于tcp层去自定义协议的
- 基于七层http协议去进行服务调用的
典型代表就是java的spring cloud了
然后基于4层的rpc调用呢
主要有典型的代表有：阿里的dubbo还有iris，还有腾讯的tars
目前市面的微服务的框架呢
除了我们刚讲的
他们服务间调用协议的不同呢
额外的那么他们使用的语言以及他们支持的其他语言的生态也是不一样的
举个列子：
比如spring cloud主要是Java系使用的。dubbo也是Java系在用
而腾讯的tars，他会支持多种不同的语言。比如说：golang PHP nodejs等等
那么假如我们抛开这个微服务的框架
能不能实现微服务呢
其实也是可以的
因为，在很多人看来
微服务的整个核心其实就是注册中心
而对于微服务里面的其他角色
比如我们常说的微服务的网关，链路追踪，配置中心等等
它主要是去辅助我们整个微服务去更好的运转
说到这里，你可能发现
其实微服务里面用到的所有的技术栈
并没有很高深，或是很冷门
微服务其实还是我们对软件工程的一个看法和理解
而对于微服务的探索
或是软件行业的探索，也没有止步
现在比较流行的，也在提出的是一个Serverless的概念
对于Serverless的概念呢，其实是基于以前的虚拟机的概念
或者是容器化的概念再进一步
也就是我们在应用的时候不需要再去购买服务器了
也不需要再去该买什么数据库了
只需要我们配置话的方式去生成
然后直接自动对接
目前的容器化和容器编排
比如说docker和k8s
他们两哥组合能够发挥很大的作用
为什么呢
因为docker它抹平了
整个系统的差异以及语言环境的差异
而对于k8s呢
它具备很好的容器管理的能力
以及弹性伸缩的能力
那么当我们将我们需要用到的资源
比如MySQL Redis，或是不同的语言环境
全部已经预置打包好环境了（镜像）
那么，对于业务的使用方，代码研发那一侧
他能够很简单的通过几个配置
然后通过k8s自动去调度
和生成的实例和资源
那么是完全能达到我们期望的Serverless的
