1.根据dubbo的架构图，画出dubbo进行一次微服务调用的时序图
按照老师的答案进行了部分修改
dubbo官网对服务的暴露和引用有两张时序图，拿过来引用一下
2.关于微服务架构（中台、领域驱动设计、组件设计原则），你有什么样的思考和认识？
技术架构都是为业务服务的，微服务、中台等内容，都是为了满足业务发展到一定阶段的需求而出现的技术理论、方法及实现的一整套体现。
随着业务的快速发展，业务需求不断变化，业务量不断提升，通常的单体应用，很难满足业务发展对系统的要求。各种问题就会爆发。单体应用的问题老师已经介绍的很详细了，我就不再列举了。举一个我所在公司的例子，在13年左右，笔者所在公司手机app，用户规模接近亿级，实际上手机后台服务还是一个单体部署的，前端依靠F5将请求负责到后台多台服务器上。数据库按照地区和功能进行了一定的拆分。曾经出过一次比较严重的问题，各个应用服务器在服务启动的时候，会缓存部分初始化的数据到服务器内存，在一次升级过程中，由于一个参数配置，导致本来只有一个地区的数据初始化的数据，变成全国所有地区的数据都初始化进来了，大量的初始化数据导致整个应用服务器jvm内存耗尽，服务响应慢，部分客户无法登陆，登陆后响应也响应缓慢。由于所有服务器部署的服务都是一样的，所以加机器也没有用。当时分析jvm内存占用，然后分析是哪部分程序导致的，然后上线补丁解决，花了大概一天多的时间才解决问题。由于客户数量众多，这个问题是一个很严重的问题。在做复盘分析的时候，我们决定将服务进行拆分，按照业务维度、重要程度等维度，将部分服务独立，渐渐的进行服务化的改造。
在企业微服务改造的过程中，如果进行微服务的拆分，服务粒度多大是一个很难的问题，经常是设计人员凭经验，觉得哪个功能模块相对独立，然后拆出一个服务，这样设计出来的微服务很难做到粒度大小合适，边界清晰。DDD是可以用来指导微服务拆分的一套完整的方法论，其中的战略设计，从业务的角度对业务进行了划分，每个划分出来的子域功能内聚，比较好的对应一个微服务，战术设计，可以指导如何从业务模型的设计到技术架构的落地。我所在公司，目前正在进行新一代核心系统的建设工作。对业务进行了建模，根据业务的类似抽象了几级的业务模型层次，技术架构的设计，承接了业务模型的设计，业务和技术之间有一种比较天然的承接关系，有利于业务在技术的落地。
从个人的观点来看，作为技术人员，我们通常的关注点在技术的模型，抽象，分离关注点等等，是有一套相对完整的方法论和从抽象到落地的实际。而对于业务需求，经常没有完善的模型和抽象，导致业务需求经常在一些零售的点上，具体落到系统中就缺少一种体系化的承接的步骤。类似DDD这类或者业务建模的方式，可以对业务需求通过一些通用语句进行聚类，抽象，整合，无论是业务还是技术都是有非常大的帮助的。
在实际落地的过程中，组件设计的各种原则，都是我们用来设计的指导，组件设计原则其实和软件设计的各类原则是有相通相似的地方的，是高内聚，低耦合，封装变化等设计思想的具体方法。
中台这个概念最近火起来，中台是企业级能力复用平台。中台的概念，更接近于企业战略，偏向对发展业务的角度来提出的。比如说的数据、业务双中台的概念。在笔者的感觉，中台更多是讲一些通用的能力的下沉，形成统一服务提供给各个业务前台进行服务，前台可以灵活的实现各类业务需求。比如我所在公司所做的将手机、网站、微信端公共需要的一些服务，比如认证、限额、支付等服务搭建统一服务进行提供等。每个公司，每个人对中台的理解都有一些不一样，我对中台的理解还需要进一步的加强。