转载

微服务的诞生以及相关技术栈

本文是一个开坑文，列出了所有笔者能想到以及接触到的微服务场景下用到的技术栈以及技术选型，将来会详细展开每一个内容

从tomcat服务到微服务的进化史

很多人刚入门时候都是从tomcat开始的，下载一个tomcat容器，然后启动startup.sh，在浏览器输入经典的 http://localhost:8080 ，就看到那个画风诡异的汤姆猫了（啊，爷春回）

web服务早期的模式其实也是如此，一台暴露在公用ip的服务器，接收来自网民的请求。

访问量多了以后，一台服务器肯定是承受不住的，所以需要引入 nginx反向代理 ，根据一定的负载均衡算法将流量路由到不同的服务器上，就会变成这样

起初，网站的功能很简单的时候，上面的结构就足以处理请求了，但是当业务规模逐渐扩大后会遇到很多问题：

所以提出了一种将模块的调用当做方法调用一样实现的结构，也就是 微服务 。不同模块提供一类业务相关功能的子集，然后通过 RPC框架 来相互调用

RPC框架要做的事情大体上就是如下图

通过 动态代理技术 将一个RPC调用的过程伪装成普通的方法调用，例如代码

int result = calculator.add(a, b);
复制代码

calculator类的add()方法就可以是通过动态代理生成的一个代理方法，背后执行的是RPC的操作

调用方请求提供方时需要实时的知晓提供方的ip和端口，用来发送请求，这里就需要用到 ZooKeeper 或者 Eureka 来实现 服务发现功能 ，这里的选型涉及到分布式领域的 CAP定理，ZooKeeper是CP，Eureka是AP

即序列化/反序列化，也就是把内存中的对象转为二进制的字节用于在网络中传输，编码解码可选择的方案有：

序列化需要关注的能力包括：

RPC框架需要支持 负载均衡 的能力，常见的负载均衡算法有随机、轮询、权重（动态权重，根据响应时间等参数来进行计算）

一般默认都会支持轮询的算法，一种实现方式就是通过在调用方通过维护一个AtomicInteger通过CAS乐观锁累加，实现轮询
权重则是更高级的负载均衡算法，静态或者动态采集下游的CPU占用、内存、线程数、相应时间来决定不同下游的优先级
基于方法或者接口的路由，因为会存在这样的情况，有两个方法，方法1耗时5s，方法2耗时50ms，在两个方法请求量差不多的情况下，如果在服务器线程数不足的时候，线程池中迟早都会堆满方法1，所以需要对不同方法或者接口路由到不同的下游