1.根据dubbo的架构图,画出dubbo进行一次微服务调用的时序图

按照老师的答案进行了部分修改

dubbo官网对服务的暴露和引用有两张时序图,拿过来引用一下

/dev-guide/images/dubbo-export.jpg
服务暴露时序图
/dev-guide/images/dubbo-refer.jpg
服务引用时序图

2.关于微服务架构(中台、领域驱动设计、组件设计原则),你有什么样的思考和认识?

技术架构都是为业务服务的,微服务、中台等内容,都是为了满足业务发展到一定阶段的需求而出现的技术理论、方法及实现的一整套体现。

随着业务的快速发展,业务需求不断变化,业务量不断提升,通常的单体应用,很难满足业务发展对系统的要求。各种问题就会爆发。单体应用的问题老师已经介绍的很详细了,我就不再列举了。举一个我所在公司的例子,在13年左右,笔者所在公司手机app,用户规模接近亿级,实际上手机后台服务还是一个单体部署的,前端依靠F5将请求负责到后台多台服务器上。数据库按照地区和功能进行了一定的拆分。曾经出过一次比较严重的问题,各个应用服务器在服务启动的时候,会缓存部分初始化的数据到服务器内存,在一次升级过程中,由于一个参数配置,导致本来只有一个地区的数据初始化的数据,变成全国所有地区的数据都初始化进来了,大量的初始化数据导致整个应用服务器jvm内存耗尽,服务响应慢,部分客户无法登陆,登陆后响应也响应缓慢。由于所有服务器部署的服务都是一样的,所以加机器也没有用。当时分析jvm内存占用,然后分析是哪部分程序导致的,然后上线补丁解决,花了大概一天多的时间才解决问题。由于客户数量众多,这个问题是一个很严重的问题。在做复盘分析的时候,我们决定将服务进行拆分,按照业务维度、重要程度等维度,将部分服务独立,渐渐的进行服务化的改造。

在企业微服务改造的过程中,如果进行微服务的拆分,服务粒度多大是一个很难的问题,经常是设计人员凭经验,觉得哪个功能模块相对独立,然后拆出一个服务,这样设计出来的微服务很难做到粒度大小合适,边界清晰。DDD是可以用来指导微服务拆分的一套完整的方法论,其中的战略设计,从业务的角度对业务进行了划分,每个划分出来的子域功能内聚,比较好的对应一个微服务,战术设计,可以指导如何从业务模型的设计到技术架构的落地。我所在公司,目前正在进行新一代核心系统的建设工作。对业务进行了建模,根据业务的类似抽象了几级的业务模型层次,技术架构的设计,承接了业务模型的设计,业务和技术之间有一种比较天然的承接关系,有利于业务在技术的落地。

从个人的观点来看,作为技术人员,我们通常的关注点在技术的模型,抽象,分离关注点等等,是有一套相对完整的方法论和从抽象到落地的实际。而对于业务需求,经常没有完善的模型和抽象,导致业务需求经常在一些零售的点上,具体落到系统中就缺少一种体系化的承接的步骤。类似DDD这类或者业务建模的方式,可以对业务需求通过一些通用语句进行聚类,抽象,整合,无论是业务还是技术都是有非常大的帮助的。

在实际落地的过程中,组件设计的各种原则,都是我们用来设计的指导,组件设计原则其实和软件设计的各类原则是有相通相似的地方的,是高内聚,低耦合,封装变化等设计思想的具体方法。

中台这个概念最近火起来,中台是企业级能力复用平台。中台的概念,更接近于企业战略,偏向对发展业务的角度来提出的。比如说的数据、业务双中台的概念。在笔者的感觉,中台更多是讲一些通用的能力的下沉,形成统一服务提供给各个业务前台进行服务,前台可以灵活的实现各类业务需求。比如我所在公司所做的将手机、网站、微信端公共需要的一些服务,比如认证、限额、支付等服务搭建统一服务进行提供等。每个公司,每个人对中台的理解都有一些不一样,我对中台的理解还需要进一步的加强。