微服务架构学习备份

名词解译作者：严肃链接：/question/19732473/answer/20851256同步与异步同步和异步关注的是消息通信机制(synchronouscommunication/asynchronouscommunication)所谓同步，就是在发出一个*调用*时，在没有得到结果之前，该*调用*就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由*调用者*主动等待这个*调用*的结果。而异步则是相反，*调用*在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在*调用*发出后，*被调用者*通过状态、通知来通知调用者，或通过回调函数处理这个调用。阻塞与非阻塞阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。微服务需要解决的问题1、开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制2、解决安全问题分布式系统两种方式参考：blogs.eom/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中间件。IrwkrrdullerS聊KGir♦呻】wncr个用于分布式的RPC中间件。IrwkrrdullerS聊KGir♦呻】wncrS闻rmycIXCJiewl!ChcuEk■£帅脚gr桐ECIcticlient询问tracker可以下载指定文件的storage；tracker返回一台可用的storage；

client直接和storage通信完成文件下载。其中tracker便是负载均衡服务器，storage是存储文件和处理上传下载请求的服务器。而另一个RPC中间件Hedwig也是类似的client询问zookeeper哪台server可以执行请求；zookeeper返回一台可用server；client直接与service完成一次RPC。zookeeper是分布式系统中一个负载均衡框架，google的chubby的一个开源实现，是Hadoop和Hbase的重要组件。同样的在http中，常听说的nginx也是一个负载均衡服务器，它面向的是分布式web服务分布式同步（数据一致性）分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。在一致性算法中paxos算法是公认的最好的算法，chubby、zookeeper中paxos是它保证一致性的核心基于消息方式的系统间通信基于远程调用方式的系统间通信分布式关键技术消息队列架构消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息。消息队伍原理服务框架架构用务注册建中心堵求直接送这履多端没有-中心代理服务器发布服务地址信息定于•服务地址信息中心会主动推送供者服务消童者服务消服务提供者服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务框架是一个点对点模型服务框架面向同构系统适合：移动应用、互联网应用、外部系统服务框架原理服务总线架构服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用服务总线是一个总线式的模型服务总线面向同构、异构系统适合：内部系统服务总线原理

台对夕桃具■.L管理监传T具分布式架构下系统间交互的5种通信模式request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。台对夕桃具■.L管理监传T具Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的.get（）,如果此时没有结果返回的话，会一直阻塞到有结果返回为止。Oneway模式：客户端调用完继续执行，不管接收端是否成功。Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。作者：知乎用户链接：/question/22764869/answer/31277656来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。分布式架构下的服务治理服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质垦服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。基于服务框架Dubbo的服务治理-服务管理对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等操作可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等操作

Dubbo原理DubhoAPP5、11肺川加19土1