微服务架构学习备份.docxVIP

名词解译作者：严肃链接：/questionanswer步与异步同步和异步关注的是消息通信机制 (synchronous communication/ asynchronous communication)所谓同步，就是在发出一个*调用*时，在没有得到结果之前，该*调用*就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由*调用者*主动等待这个*调用*的结果。而异步则是相反，*调用*在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在*调用*发出后，*被调用者*通过状态、通知来通知调用者，或通过回调函数处理这个调用。阻塞与非阻塞阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。微服务需要解决的问题1、开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制2、解决安全问题分布式系统两种方式参考：/chulung/p/5653135.html水平扩展假设我们有一台服务器，它可以承担1百万/秒的请求，这个请求可以的是通过http访问网页，通过tcp下载文件，jdbc执行sql，RPC调用接口…，现在我们有一条数据的请求是2百万/秒，很显然服务器hold不住了，会各种拒绝访问，甚至崩溃，宕机，怎么办呢。一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担1百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。这种方式我们称之为水平扩展。如何实现请求的平均分配便是负载均衡了。垂直扩展另一个例子，我们现在有两个数据请求，数据1 (90万)，数据2 (80万)，上面那台机器也hold不住，我们加一台机器来负载均衡一下，每台机器处理45万数据1和40万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分分布式负载均衡前面我们谈到了分布式来解决性能问题，但其附带的问题是怎么分布，即如何负载均衡。这里要解决的问题是当客户端请求时，应该让它请求分布式系统中哪一台服务器，通常的做法是通过一台中间服务器来给客服端分配目标服务器。这里同样拿两个不同的分布式系统做说明，下图左边是分布式文件系统FastDFS,右边是一个用于分布式的RPC中间件。FastDFS的一次文件下载请求过程是这样的 1.client询问tracker可以下载指定文件的storage； 2.tracker返回一台可用的storage； 3.client直接和storage通信完成文件下载。其中tracker便是负载均衡服务器，storage是存储文件和处理上传下载请求的服务器。而另一个RPC中间件Hedwig也是类似的1.client询问zookeeper哪台server可以执行请求；2.zookeeper返回一台可用server；3.client直接与service完成一次RPC。zookeeper是分布式系统中一个负载均衡框架，google的chubby的一个开源实现，是Hadoop和Hbase的重要组件。同样的在http中，常听说的nginx也是一个负载均衡服务器，它面向的是分布式web服务器分布式同步（数据一致性）分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。在一致性算法中paxos算法是公认的最好的算法，chubby、zookeeper中paxos是它保证一致性的核心基于消息方式的系统间通信基于远程调用方式的系统间通信分布式关键技术消息队列架构消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息。消息队伍原理服务框架架构服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务框架是一个点对点模型服务框架面向同构系统适合：移动应用、互联网应用、外部系统服务框架原理服务总线架构服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务总线是一个总线式的模型服务总线面向同构、异构系统适合：内部系统服务总线原理分布式架构下系统间交互的5种通信模式request/response模式（同步模式）：客户端发起请求一直阻塞到服