微服务架构 在容器技术大火的当下,将后台的应用微服务化,无疑是最优的选择,但微服务化并不是简简单单就能实现的. 微服务的概念是通过对应用功能的解耦.在明确各自的作用,将其分散到各自独立的运行环境中. 早期服务程序大都是单体的,它会囊括多种功能,这在编写代码,调试程序时都是比较耗时耗力的,并且一个功能庞大的单体服务程序,只要某个环节出现了问题,则会较大概率的导致整体的崩溃. 而当将这些功能打散后,规模和体积将会变得更加轻量化,代码编写只需完成其单一场景的作用,调试必将将会变得简单,而在编译/打包/部署等环节都会节约不少时间,这将大大的提高开发的效率. 从当下主流的微服务架构来说,首先会依据功能划分出Service Gateway,来自用户的 Request 到达后,这些网关负责鉴权与路由.通过验证的请求,会被该网关转发到内部的实际的某个微服务中去,而后此微服务完成功能后应答网关,网关再回应用户.这整个流程应该是异步的,尽量避免因某个环节导致整体的阻塞. 服务间调用 在将服务拆分后,会导致一个问题,那就是服务间复杂的依赖关系.比如现在最火的 SOA 型的微服务架构也是如此. 当将一个单体应用拆分开后,不可避免的需要于服务间进行一些数据共享,而共享方式则就是服务间调用. 基于此,微服务之间也必须要有明确的划分界限:哪下服务应该是对外的,哪些微服务又该是对内的? 比如在线好友的查询服务网关中,对外的服务很好确认,而对内的微服务相对较难界定.可以将专门查询好友数据的功能单一实现,通过统一的API,去查询好友数量,好友资料,好友在线状态等. 而有些时候,微服务间可能会出现数据互相依赖的现象,即服务A调用服务B去完成某项功能时,服务B在运行中又可能需要调用A的接口获取数据,这将会导致微服务间层级错落的现象,此时应该尽量将相互依赖的功能划分独立出来,否则在后来可能越来越背离微服务的架构旨意.