我也谈谈微服务

微服务是大型分布式系统的基本组成部分，在面对海量用户时在设计上考虑横向扩展后，应用在集群间采用RPC调用，微服务的使用与目前互联网服务的体量是分不开的，是控制复杂度的一种手段。

早期大家在处理http请求时由于单机linux的文件句柄数量上限，或单web容器的单机极限等原因开始采用服务器集群(老外叫的更贴切-服务器农场，含义既跟老农养鸡养鸭一样，养一堆服务器)，每个服务器处理一部分http请求；每个服务器的处理能力是不一样的(新老机器混杂，虚拟化超卖，容器隔离性能)此时就要考虑如何让机器物尽其用，能者多劳，不能者少劳，负载均衡设施那是必不可少的(无论是轮负载还是硬负载)，这里还只是http层的处理；

大家知道http就是个文本协议，传来传去对浏览器而言就是拿到服务器上传回的文本，浏览器对远方服务怎么生成这个并不关心。现在大多数网站已经都是动态网站了，比如淘宝首页上的各种商品，每天都有上千万的商家进行发布和编辑，我们看到的每个时间段都不一定是同样的东西，都是动态的。而网页中又会混杂很多静态的东西， 例如页面的js，图片jpg/png等东西，从性能优化的角度讲，这两块东西肯定是各用一套专门的服务来处理才是最优解， 业内对纯http与后端动态服务的处理也有若干方案，如动态语言+fastCGI，Java方案有Servlet。 在此种方案的基础上， 如果网站规模很大， 希望前端工程与后端工程的人解耦，走rest方式让两个团队的人可以各干各的，只要最后做系统集成时才联调一下也是个不错的选择。

以上只是http容器与一个宏观后端服务器间的交互，那么当规模再大，后端服务之间也需要拆分了，每个服务做自己的事，控制一定量的复杂度， 比如让一个业务开发再去想用户的账户都怎么管理，异常怎么处理太浪费时间了，不利于快速冲业务。几年前J2EE对此的答案就是SOA架构，那是还没有走分布式架构体系，相关服务的处理还是考虑抽象出ESB总线，可以与计算机主板的总线对比，各个部件（组件）间的通信都通过总线（ESB）来处理。进入分布式系统的时代后，服务仍然在，只是变成了所谓的微服务了，从服务的角度并没有什么不同。

至此，web app从进程内通信转向进程间通信的趋势已经尘埃落定了，通过增加服务器的方式进行横向扩展也只能采用进程间通信的方式。剩下的就是如何让工程师更快速方便的批量将应用的代码发布上线，对于java应用来说，就是尽可能快的将war包（传统，提供http）或jar包（springboot 服务式）复制到servlet容器（依赖容器启动）或自包含自启动的jar包（本质也是提供tcp服务端口连接）。 此处如果运维支撑环境做得不够好，会有很多环境上的线上问题，因为开发的日常环境可能与线上环境不同，运维人员此时努力要做的就是维护日常与线上环境的基线， 不要有任何的不同， 避免出现诡异的问题。 这个问题现在有一种方式可以解，前景看起来还不错，就是用docker化，让开发保证自己打出的docker包是可运行的，由于docker容器与OS之间也做到了一层隔离，docker自己的生态环境内不会受到外部各种linux方言版本的影响，理论上讲问题会更少，能做到拆箱即用。如果能大面积铺开docker形式的运维部署系统，devops的时代也就到了，系统管理员只需要关注系统的安装，对于黑箱的docker发布来说，想办法快速在集群间分发下去，启动即可。

不得不佩服美国同行的理论能力，在1985年就已经发布了论文解决大规模分布式系统的配置管理问题 Dynamic Configuration for Distributed Systems,

https://spiral.imperial.ac.uk/bitstream/10044/1/452/1/Dynamic Configuration for Distributed.pdf

那时候14K的猫都还没有， BBS还在初级阶段，就已经能YY到今天大规模分布式系统要解决的问题了。

题图：福克斯RS

福克斯RS以普通福克斯为基础研发出来的性能车型，但绝大部分的零部件都经过重新的设计。在外观方面，它采用了全新的车身空气动力学套件，使其不仅拥有了更为激进的外形，而且空气动力学性能更加优异。

动力方面：全新福克斯RS搭载的是一台2.3T涡轮增压发动机，其最大输出功率为350马力，峰值扭矩为440牛·米，超增压模式下可达到470牛·米。传动系统匹配6速手动变速箱，并配备有四驱系统。官方称，该车0-100km/h加速时间为4.7秒，最高车速为266km/h。

---

文章来自微信平台「麦芽面包」
微信公众号「darkjune_think」
转载请注明。