接上文《软件设计不是CRUD（18）：像搭积木一样搭建应用系统（上）——单个应用系统的搭建过程》
之前几篇文章，我们讨论的都是单体应用系统如何进行模块化设计，最多也就是集群化在集群环境中工作的单体应用系统（实际上单体应用是集群化部署，还是单节点部署，都不影响其设计过程）。但是如今应用系统的建设环境，相当一部分是在服务化场景下进行的。也就是说建设的应用系统，实际上是多个新建的和已有的应用系统共同构成的一个系统平台，并联合对外提供服务。那么这样的服务化的、平台化的系统，是否也适用基于业务抽象的建设方式呢？
除和业务相关的服务集群建设工作外，以上提到的绝大多数组件都是玩具，属于架构师需要掌握的集成选型、集成设计能力，但不是架构师最核心的能力。有的读者可能还不太认同这样的观点，认为架构师主要的工作就是将这些纯技术的工具有序搭建起来协作运行。在这里笔者不太愿意去证明，后一种观点是否正确，不过笔者愿意通过本文的描述，论述前一个观点的正确性。
1、微服务化系统建设中的常见问题
1.1、（偏向）技术侧的问题
我们先来梳理一下在微服务化系统建设过程中，那些常见的、偏向技术侧的问题。这些问题有一个共同特点，就是不太需要甚至完全不需要结合具体的业务场景来寻求问题的解决办法。例如：
如何管理这些服务？这个管理要求至少包括对服务的发现、注册、查询、剔除、归类等。
微服务化的系统建设，很重要的技术选型工作就是寻找一款符合技术要求的服务注册组件。目前流行的相关服务组件有Nacos，Consul，Eureka（不再推荐）等。
如何归纳和集中，分散在各个服务中的多个接口，方便调用者学习、查询和调用？
一般来说外部的调用者，都是基于网关发起对微服务化系统的调用。这样做最明显的好处是，外部调用者无需知道将调用的接口功能来源于哪个具体的服务，也不需要知道调用这个接口功能后，各个服务间会如何协同，最终完成工作。目前常用的网关组件是Spring Cloud Gateway。当然研发团队如果对网关有特殊要求，也可以进行自研，例如有的技术团队会选择将服务编排能力、部分服务监管能力、网关路由等能力集中在一个管理服务统一进行操作、展示。
各个服务间一定存在调用要求，也就是协同工作以完成一个整体业务工作的要求。那么这些服务应该如何统一调用方式？
微服务化系统中的各个服务，需要有个规范化的方式提供接口。一般来说有两种方式，一种是基于HTTP-Restful形式提供的API接口调用，另一种是基于TCP协议的RPC接口调用。这两种方式并不是说某一种方式一定比另一种方式好，而是说各有各的优点：
调用形式 调用性能 传输协议 <