RPC方式
RPC的方式就是远程函数调用，像RESTFul，gRPC, DUBBO 都是这种方式。它一般是同步的，可以马上得到结果。在实际中，大多数应用都要求立刻得到结果，这时同步方式更有优势，代码也更简单。
服务网关（API Gateway）
熟悉微服务的人可能都知道服务网关（API Gateway）。当UI需要调用很多微服务时，它需要了解每个服务的接口，这个工作量很大。
于是就用服务网关创建了一个Facade，把几个微服务封装起来，这样UI就只调用服务网关就可以了，不需要去对付每一个微服务。下面是API Gateway示例图：
服务网关（API Gateway）不是为了解决微服务之间调用的紧耦合问题，它主要是为了简化客户端的工作。其实它还可以用来降低函数之间的耦合度。
有了API Gateway之后，一旦服务接口修改，你可能只需要修改API Gateway， 而不必修改每个调用这个函数的客户端，这样就减少了程序的耦合性。
服务调用
可以借鉴API Gateway的思路来减少RPC调用的耦合度，例如把多个微服务组织起来形成一个完整功能的服务组合，并对外提供统一的服务接口。这种想法跟上面的API Gateway有些相似，都是把服务集中起来提供粗颗粒（Coarse Granular）服务，而不是细颗粒的服务（Fine Granular）。
但这样建立的服务组合可能只适合一个程序使用，没有多少共享价值。因此如果有合适的场景就采用，否则也不必强求。虽然我们不能降低RPC服务之间的耦合度，却可以减少这种紧耦合带来的影响。
降低紧耦合的影响
什么是紧耦合的主要问题呢？就是客户端和服务端的升级不同步。服务端总是先升级，客户端可能有很多，如果要求它们同时升级是不现实的。它们有各自的部署时间表，一般都会选择在下一次部署时顺带升级。
一般有两个办法可以解决这个问题：
同时支持多个版本：这个工作量比较大，因此大多数公司都不会采用这种方式。
服务端向后兼容：这是更通用的方式。例如你要加一个新功能或有些客户要求给原来的函数增加一个新的参数，但别的客户不需要这个参数。这时你只好新建一个函数，跟原来的功能差不多，只是多了一个参数。这样新旧客户的需求都能满足。它的好处是向后兼容（当然这取决于你使用的协议）。
它的坏处是当以后新的客户来了，看到两个差不多的函数就糊涂了，不知道该用那个。而且时间越长越严重，你的服务端可能功能增加的不多，但相似的函数却越来越多，无法选择。
它的解决办法就是使用一个支持向后兼容的RPC协议，现在最好的就是Protobuf gRPC，尤其是在向后兼容上。
它给每个服务定义了一个接口，这个接口是与编程语言无关的中性接口，然后你可以用工具生成各个语言的实现代码，供不同语言使用。函数定义的变量都有编号，变量可以是可选类型的，这样就比较好地解决了函数兼容的问题。
就用上面的例子，当你要增加一个可选参数时，你就定义一个新的可选变量。由于它是可选的，原来的客户端不需要提供这个参数，因此不需要修改程序。
而新的客户端可以提供这个参数。你只要在服务端能同时处理这两种情况就行了。这样服务端并没有增加新的函数，但用户的新需求满足了，而且还是向后兼容的。
微服务的数量有没有上限？
总的来说微服务的数量不要太多，不然会有比较重的运维负担。有一点需要明确的是微服务的流行不是因为技术上的创新，而是为了满足管理上的需要。单体程序大了之后，各个模块的部署时间要求不同，对服务器的优化要求也不同，而且团队人数众多，很难协调管理。
把程序拆分成微服务之后，每个团队负责几个服务，就容易管理了，而且每个团队也可以按照自己的节奏进行创新，但它给运维带来了巨大的麻烦。所以在微服务刚出来时，我一直觉得它是一个退步，弊大于利。但由于管理上的问题没有其他解决方案，只有硬着头皮上了。
值得庆幸的是微服务带来的麻烦都是可解的。直到后来，微服务建立了全套的自动化体系，从程序集成到部署，从全链路跟踪到日志，以及服务检测，服务发现和注册，这样才把微服务的工作量降了下来。
虽然微服务在技术上一无是处，但它的流行还是大大推动了容器技术，服务网格（Service Mesh）和全链路跟踪等新技术的发展。不过它本身在技术上还是没有发现任何优势。
直到有一天，我意识到单体程序其实性能调试是很困难的（很难分离出瓶颈点），而微服务配置了全链路跟踪之后，能很快找到症结所在。看来微服务从技术来讲也不全是缺点，总算也有好的地方。但微服务的颗粒度不宜过细，否则工作量还是太大。
一般规模的公司十几个或几十个微服务都是可以承受的，但如果有几百个甚至上千个，那么绝不是一般公司可以管理的。尽管现有的工具已经很齐全了，而且与微服务有关的整个流程也已经基本上全部自动化了，但它还是会增加很多工作。
Martin Fowler几年以前建议先从单体程序开始（详见 MonolithFirst），然后再逐步把功能拆分出去，变成一个个的微服务。但是后来有人反对这个建议，他也有些松口了。
如果单体程序不是太大，这是个好主意。可以用数据额库表的数量来衡量程序的大小，我见过大的单体程序有几百张表，这就太多了，很难管理。正常情况下，一个微服务可以有两、三张表到五、六张表，一般不超过十张表。但如果要减少微服务数量的话，可以把这个标准放宽到不要超过二十张表。
用这个做为大致的指标来创建微程序，如果使用一段时间之后还是觉得太大了，那么再逐渐拆分。当然，按照这个标准建立的服务更像是服务组合，而不是单个的微服务。不过它会为你减少工作量。只要不影响业务部门的创新进度，这是一个不错的方案。
到底应不应该选择微服务呢？如果单体程序已经没法管理了，那么你别无选择。如果没有管理上的问题，那么微服务带给你的只有问题和麻烦。其实，一般公司都没有太多选择，只能采用微服务，不过你可以选择建立比较少的微服务。如果还是没法决定，有一个折中的方案，“内部微服务设计”。
内部微服务设计
这种设计表面上看起来是一个单体程序，它只有一个源代码存储仓库，一个数据库，一个部署，但在程序内部可以按照微服务的思想来进行设计。它可以分成多个模块，每个模块是一个微服务，可以由不同的团队管理。
用这张图做例子。这个图里的每个圆角方块大致是一个微服务，但我们可以把它作为一个单体程序来设计，内部有五个微服务。
每个模块都有自己的数据库表，它们都在一个数据库中，但模块之间不能跨数据库访问（不要建立模块之间数据库表的外键）。
“User”（在Conference Management模块中）是一个共享的类，但在不同的模块中的名字不同，含义和用法也不同，成员也不一样（例如，在“Customer Service”里叫“Customer”）。
DDD（Domain-Driven Design）建议不要共享这个类，而是在每一个有界上下文（模块）中都建一个新类，并拥有新的名字。
虽然它们的数据库中的数据应该大致相同，但DDD建议每一个有界上下文中都建一个新表，它们之间再进行数据同步。
这个所谓的“内部微服务设计”其实就是DDD，但当时还没有微服务，因此外表看起来是单体程序，但内部已经是微服务的设计了。
它的书在2003就出版了，当时就很有名。但它更偏重于业务逻辑的设计，践行起来也比较困难，因此大家谈论得很多，真正用的较少。
直到十年之后，微服务出来之后，人们发现它其实内部就是微服务，而且微服务的设计需要用它的思想来指导，于是就又重新焕发了青春，而且这次更猛，已经到了每个谈论微服务的人都不得不谈论DDD的地步。不过一本软件书籍，在十年之后还能指导新技术的设计，非常令人钦佩。
这样设计的好处是它是一个单体程序，省去了多个微服务带来的部署、运维的麻烦。但它内部是按微服务设计的，如果以后要拆分成微服务会比较容易。至于什么时候拆分不是一个技术问题。
如果负责这个单体程序的各个团队之间不能在部署时间表，服务器优化等方面达成一致，那么就需要拆分了。
当然你也要应对随之而来的各种运维麻烦。内部微服务设计是一个折中的方案，如果你想试水微服务，但又不愿意冒太大风险时，这是一个不错的选择。
结论
微服务之间的调用有两种方式，RPC和事件驱动。事件驱动是更好的方式，因为它是松耦合的。但如果业务逻辑是紧耦合的，RPC方式也是可行的（它的好处是代码更简单），而且你还可以通过选取合适的协议（Protobuf gRPC）来降低这种紧耦合带来的危害。
由于事件溯源和事件通知的相似性，很多人把两者弄混了，但它们实际上是完全不同的东西。微服务的数量不宜太多，可以先创建比较大的微服务（更像是服务组合）。
如果你还是不能确定是否采用微服务架构，可以先从“内部微服务设计”开始，再逐渐拆分。
