1.微服务架构 --- SOA架构思想的一种实现
定义: 采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信,例如RPC、HTTP等。 服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。 特征: 1.通过服务实现组件化 传统实现组件的方式是通过库,传统组件和应用一起运行在进程中,组件的变化意味着整个应用要重新部署。 通过服务来实现组件,意味着将应用拆散为一系列的服务运行在不同的进程中,单个服务的变化,只需重新部署对应的服务进程,不影响应用的运行 将服务作为组件可更明确的定义组件的边界,因为服务之间的调用时跨进程的,清晰的边界和职责定义是设计时必须考虑的。 2.按业务能力来划分服务与组织团队 传统开发方式中,我们将工程师按技能专长分层为前端层、中间层、数据层,前端对应的角色为UI、页面构建师等,中间层对应的角色为服务端业务开发工程师,数据层对应着DBA等角色 微架构,将应用按业务功能,划分为不同的服务,每个服务都要求在对应业务领域的全栈(从前端到后端)软件实现,从界面到数据库存储到外部沟通协作等等。 3.服务即产品 4.去中心统一化 你可以针对不同的业务服务特征选择不同的技术平台或产品,有针对性的解决具体的业务问题 5.基础设施自动化 6.进化设计 应用: 问题:如果将一个单一应用拆分为多个服务? 一个原则: 单一服务提供的功能是可以独立被替换和升级的。 即:如果有A和B两个功能,如果A功能发送变化时同时B功能也需要变化,那么A和B这两个功能应该被划在一个服务中
2.关于RPC
首先了解什么叫RPC,为什么要RPC,RPC是指远程过程调用,也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。
比如说,一个方法可能是这样定义的: Employee getEmployeeByName(String fullName) 那么:- 首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立TCP连接,远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接,调用结束后就断掉,也可以是长连接,多个远程过程调用共享同一个连接。
- 第二,要解决寻址的问题,也就是说,A服务器上的应用怎么告诉底层的RPC框架,如何连接到B服务器(如主机或IP地址)以及特定的端口,方法的名称名称是什么,这样才能完成调用。比如基于Web服务协议栈的RPC,就要提供一个endpoint URI,或者是从UDDI服务上查找。如果是RMI调用的话,还需要一个RMI Registry来注册服务的地址。
- 第三,当A服务器上的应用发起远程过程调用时,方法的参数需要通过底层的网络协议如TCP传递到B服务器,由于网络协议是基于二进制的,内存中的参数的值要序列化成二进制的形式,也就是序列化(Serialize)或编组(marshal),通过寻址和传输将序列化的二进制发送给B服务器。
- 第四,B服务器收到请求后,需要对参数进行反序列化(序列化的逆操作),恢复为内存中的表达方式,然后找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值。
- 第五,返回值还要发送回服务器A上的应用,也要经过序列化的方式发送,服务器A接到后,再反序列化,恢复为内存中的表达方式,交给A服务器上的应用