接口中的方法在实现类中必须是被显示声明为public的吗？
接口中的方法在实现类中不一定需要被显示声明为public。
在Java中，接口中的方法默认是public的，因此在实现类中不需要再次声明。但是，如果接口中的方法被声明为default或static，那么在实现类中则需要显式声明相同的方法修饰符。
例如，如果接口中的方法是default修饰符，那么在实现类中必须使用default修饰符来声明相同的方法，否则编译器会报错。同样地，如果接口中的方法是static修饰符，那么在实现类中也必须使用static修饰符来声明相同的方法。
总之，对于接口中的public方法，实现类中不需要显式声明为public，但对于default和static方法，实现类中需要显式声明相同的方法修饰符。
在微服务架构下，如何实现接口调用链路的跟踪？
在传统的单应用架构下，接口的日志监控还是非常简单的，但是随着分布式、微服务架构的兴起，我们会面对更为复杂的服务交互关系；
也就是说，以往的系统，更多的是A系统调用B系统，而现在可能面对这A->B->C->D，而在这种情况下，如果没有链路跟踪的方案，那么查找和定位问题就会非常困难。
理论基础
Google公司研发了Dapper分布式跟踪系统，并发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》；
目前行业内大部分的分布式跟踪方案都是基于这篇论文来实现的；这篇论文中提到了几个比较重要的概念：
annotation-based，基于标注：在程序代码或中间件中，定义一个全局的annotation，可以把这个看做是一个追踪ID；在请求链路中，每一次远程调用都要带着这个ID（通常都是通过代码埋点实现）；
跟踪树和span：在跟踪树结构中，通过parentId和spanId可以有序地把所有的关系串联起来，达到记录业务流的作用；例如A->B->C和D；那么：
A：parentId=null、spanId=1；
B：parentId=1、spanId=2；
C：parentId=2、spanId=3；
D：parentId=2、spanId=4；
实现方案
zipkin：Twitter公司的zipkin是Google Dapper系统的开源实现，zipkin是严格按照Dapper论文来实现的；zipkin的功能包括数据的收集、存储、查找和展现，一应俱全；
Spring Cloud Sleuth：如果使用Spring全家桶的话，通常可以使用Sleuth来做服务之间调用提供链路追踪；使用Sleuth的时候，也可以和zipkin做集成，将搜集到的信息发送到zipkin，利用zipkin进行数据的存储和展示；
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
外部接口如何统一api地址？
一个非常好的问题。可以试试如下方法：
1，第三方api，使用nginx代理转发
Nginx配置路由转发时，重新拼接路径和参数。
2，自己开发的api，使用url变量，或者在请求参数中增加路由信息
1）路径中包含参数，比如url/{name}，Java开发时可以使用@PathVariable读取
2）请求体参数中包含路由信息，解析得到后，实现判断逻辑
一个外部接口如何统一API地址，这个问题其实是接口网关如何设计。
接口网关的整体架构如下图一所示。
那API-Center对外提供的API地址如何设计呢？
通常的设计方案为 https://${domain}/api-gatway?interface=${interface}
例如上述图中，内部服务包含了订单域，账户域、支付域等业务域，各自定义众多的Dubbo服务接口。
那接口网关如何设计呢？其实就是建立接口映射机制，即类似如下(为了显示更有好，省略了dubbo服务的包名)
interface Dubbo Service
api-createOrder OrderService#createOrder
api-updateOrder OrderService#createOrder
这样对于接口网关的使用方，传入的接口名称为 api-createOrder，但经过网关的转发就能调用到内部的接口。
当然接口网关的设计通常还需包含如下几个设计要点：
1、签名验证
2、协议转换(http接口参数与Dubbo参数映射、返回结果映射)
3、服务发现
4、限流、降级