超级会员免费看
本文探讨了数据中心内部微服务如何通过RPC进行相互调用，重点介绍了Dubbo的二进制RPC协议Hessian2。内容包括：数据传输的优化选择二进制协议，解决协议约定问题的Hessian2自描述特性，以及RPC传输中的Netty网络框架。此外，还提及了在微服务架构中，面对JAR依赖管理和性能损耗，Spring Cloud的RESTful方式作为另一种选择。
前面我们讲了两个常用文本类的RPC协议，对于陌生人之间的沟通，用NBA、CBA这样的缩略语，会使得协议约定非常不方便。
在讲CDN和DNS的时候，我们讲过接入层的设计，对于静态资源或者动态资源静态化的部分都可以做缓存。但是对于下单、支付等交易场景，还是需要调用API。
对于微服务的架构，API需要一个API网关统一的管理。API网关有多种实现方式，用Nginx或者OpenResty结合Lua脚本是常用的方式。在上一节讲过的Spring Cloud体系中，有个组件Zuul也是干这个的。
数据中心内部是如何相互调用的？
API网关用来管理API，但是API的实现一般在一个叫作Controller层的地方。这一层对外提供API。由于是让陌生人访问的，我们能看到目前业界主流的，基本都是RESTful的API，是面向大规模互联网应用的。
在Controller之内，就是咱们互联网应用的业务逻辑实现。上节讲RESTful的时候，说过业务逻辑的实现最好是无状态的，从而可以横向扩展，但是资源的状态还需要服务端去维护。资源的状态不应该维护在业务逻辑层，而是在最底层的持久化层，一般会使用分布式数据库和ElasticSearch。
这些服务端的状态，例如订单、库存、商品等，都是重中之重，都需要持久化到硬盘上，数据不能丢，但是由于硬盘读写性能差，因而持久化层往往吞吐量不能达到互联网应用要求的吞吐量，因而前面要有一层缓存层，使
订阅专栏 解锁全文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
