服务治理演进与微服务

前言

以前经常提到微服务，而且微服务已经经过2014年后演变成大部分公司的主流技术架构设计，经过了很多市场产品的考验，想简单说说微服务的演进。

1. 大型单体应用

实际上很多应用的第一个阶段很可能是大型单体应用，在0几年很流行，was，weblogic等热部署能力，即使现在手机端app也在用，那个时候部署一个企业应用很慢，很重，需要小型机，大型机等，这些在现在可能还会在一些企业或者xx部门有遗留。

然而大型单体应用并非整体化部署，而是模块化能力，部署一般而言是部署某个模块

实际上服务注册的能力也是有的，一般而言是消息总线，后来有soap协议这些webservice能力。但是这些费用比较高，常用的还是Tomcat单体应用，这些模块化能力就要自己开发了热部署能力，当时很多商业公司用servlet封装了很多各种的框架，直到Spring的3.2版本出现，EJB思想得到了极大地简化和应用。

实际上没有绝对的微服务，微服务的划分也没有绝对的界限。在大型单体应用时，服务一般有厚重的管理后台，消息总线等来治理服务，笔者并未过多的经历这个年代，仅仅通过现在的存留应用推断罢了。

 

2. 嵌入式微服务

微服务的爆发阶段在2014年作用，那个时候互联网兴起，流量红利变现，基本上绝大部分互联网公司都是流量公司，需要对业务更快的迭代，快就是那个时候的主流，写个app都能获取投资的时代。

为了快速的迭代业务，要求应用发布快，发布周期短，发布内容少，比如Google一些业务一年发布5000次，微服务就被带火了，尤其是Spring的完善和Spring boot的发布。当大量的微型应用发布时，服务的管理就成为了难题。Spring Cloud在那时候由奈飞开源而出，然而每个公司的业务与要求不同，没办法通用，需要二次开发才能应用。

实际上在SpringCloud之前也是有RPC的dubbo的，但是由于开源的摆烂，在捐给Apache之前已经僵死状态。

这个时候服务的发现交给了注册中心，管理软件直接注册中心管控应用，调节流量，做到微服务的能力的sdk集成在框架中，诞生了各种框架Spring Cloud，dubbo，thift等……

好处是：可以治理各种业务，服务注册，流量管控等都有很完善的解决方案

劣势是：sdk与框架强绑定，没法更换，就算把算法提取出来，换个框架，换个语言只能重新适配

 

3. sidecar微服务

随着容器技术的兴起，开发语言多样，sdk不限等，还有容器本身的特性-镜像的使用，急需一种方式解决微服务的服务治理的能力，需要对语言不敏感，需要对协议不敏感，独立于应用之外service mesh的概念开始兴起

sidecar，即上面的这个东西，特点是有个额外的副驾驶，专门处理额外的情况

 

 就相当于把框架的sdk的与业务无关的治理能力抠出来，发布独立的服务，专门用于非功能用途。这样就仅仅适配协议即可，无需根框架强绑定了，业务也不需要写一些服务注册，流量治理的代码了，都给了sidecar的边车完成。开源的sidecar设计有很多，比较成熟，各有优劣。

这种做法的好处是业务专注于业务，什么代码都不写，只写业务，但是治理更加复杂，管理成本增大，一套健壮的管理监控系统很关键。

4. service less

随着云厂商的部署完善，serviceless出现了，所谓serviceless并不是我们不需要这一系列的能力，比如Redis基础服务，服务监控，流量控制等，而是云厂商提供了，简单集成即可，完成只写业务的主业😅，简单来讲，就是集成功能，完成应用开发。开发要求进一步降低，真正的代码搬砖。

总结

实际而言，计算机兴起不过20年，现在基本上各个方面都依赖计算机程序了，业务开发已经发展为搬砖了。然而实际上，很多应用实际并发并不大，绝大部分tps不超过100，只有寡头的企业才会应用高并发的情况。对于微服务而言，也并不是绝对的好处，只有适合自己的架构设计才是好设计。即使是微服务架构设计，也并非需要mesh，如果规模、基建并不成熟，sdk集成也是很好的选择。另外随着saas的能力建设，底层原理越来越模糊，系统靠设计，设计靠算法，然而大部分还是业务，了解计算机原理还是很关键的，比如cpu 内存 磁盘（机械 ssd）网络 gpu，进而依靠这些硬件的能力有了redis mysql等，有了分布式，又有了副本集，这些又需要各种算法raft、主从等。

所以只有最适合的设计，没有最好的，架构是演进的。基础很重要，这些框架或者热度炒都是使用计算机的硬件能力通过算法达到某些目的。