第二十三期 AMA 掘金团队请来了蚂蚁金服高级技术专家-- 章耿做了为期三天的 Ask Me Anything (AMA) 活动（活动已结束）。我们在此精选了一些来自用户的提问及章耿的回答。

提醒：本期Java、Spring、微服务主题的 AMA 还有不到 12 小时结束，欢迎前去提问，传送门：https://juejin.cn/pin/6844910427462172679

关于章耿

蚂蚁金服高级技术专家--章耿，花名余淮，目前在蚂蚁金服中间件团队服务与框架组负责开发框架与 SOFAStack 开源工作。

社区小伙伴精选提问

架构、技术、需求之间的关系应该是怎么样？ -@火鸡turkey

您好，想问下你觉得架构、技术、需求之间的关系应该是怎么样？对于架构设计而言，应该先满足目前的需求还是未来技术？先谢谢您的回复

我一直认为架构是随着业务发展（需求）不断演进而来的，不需要在十万用户的时候就去想好亿级用户的架构，不同的业务规模你选择的技术点肯定是不一样的。很多人从一开始就会引入业界领先一些架构，但在较小的业务规模下反而会引入复杂度。所以对架构设计而言，满足目前的需求是必须的，但是满足的同时也要往前看看未来两到三年会到一个什么规模，给未来留下一些架构扩展能力（特别是一些架构平滑替换能力），这样才能随着业务发展一起实现”可持续发展的演进式架构“。

成长为架构师需要什么样的平台和环境呢？ -@日立在掘金

您好，我想请教下，成长为架构师需要什么样的平台和环境呢？小公司就职，业务量就那么大，没有架构，至少要去大平台么？

嗯平台和环境肯定是很重要的。小型公司可能系统架构都比较简单，每个人负责的东西也较多，所以在小型公司你可能接触的技术面会比较全，但是由于业务规模在哪里技术深度可能就不会那么深了，如果有机会还是需去大平台体验下。

到底什么样的公司适合微服务架构？ -@西内

微服务这个概念很火，想问请教下到底什么样的公司适合微服务架构？例如：公司规模，项目有什么要求？

可以先看下”康威定律“，其实采用微服务，不是说什么体量什么规模才可以用微服务架构，其实你准备的好了就可以，不需要为了微服务而微服务。当你的业务具备可拆分性、组织架构职责清晰，引入微服务不会给开发同学带来协作负担的时候，就可以采用微服务架构了。

怎么划分微服务的粒度？ -@莫在逍遥

我想问下，怎么划分微服务的粒度，有没有什么类似的例子借鉴

其实很多地方都能看到微服务拆分的几个原则：

单一职责、高内聚低耦合

服务粒度适中

考虑团队结构

以业务模型切入

演进式拆分

避免环形依赖与双向依赖

这些原则应该可以快速套到你的实际项目里去吧。

如何解决服务拆分后会出现微服务调用微服务的情况，导致效率很慢的问题？ -@黑先生一号

请问，服务拆分后会出现微服务调用微服务的情况，导致效率很慢，接口的QPS很低，这块有什么好的解决方案可以分享下吗

当服务拆分后链路过长是会有这样的问题，在不改变业务代码的情况下，一方面可以看下 RPC 调用方式是否有性能提升的空间（例如http换成tcp），另外一方面可以看下服务粒度是否适中，如果太细的话，可以进行一定的服务聚合（例如很多 RPC 变成本地调用）。

组件与组件之间如何达到一个最低点的低耦合度？ -@Jack-rainbow

你好，大牛。我想咨询下项目中业务组件及公共组件，如何管理及维护呢？在项目中编写组件时，组件与组件之间如何达到一个最低点的低耦合度，您方便讲讲吗？非常期待您的回复。

你说的业务组件和公共组件是那种有个统一管控的地方，业务系统可以按需选择集成的那种吗？如果是的话，那我觉得组件应该是依赖一个公共核心部分，而组件之间应该是尽量是无依赖的，如果非要交互也应该是通过 spi 或者消息等进行解耦的。

微服务强依赖怎么解决？ -@solution

微服务强依赖怎么解决

微服务强依赖我觉得在实际过程中应该比较常见吧。如果业务能解耦看是是否能通过 MQ 或者异步的方式解耦变成弱依赖。如果不行，那只能通过一些服务保护机制，例如熔断、限流、降级等措施来保证服务可用性。

微服务的优点和带来的好处？ -@AsyncIns

章哥，介绍一下微服务的优点和带来的好处。还有微服务的适用场景😀😀。谢谢章哥

微服务带来的好处很多啊，例如：

业务逻辑更加内聚，功能易于独立的开发维护

松耦合，开发部署等都独立，方便快速迭代

可以跨不同的语言、技术栈

可以部署在低配的环境上

等等

当然微服务架构带来的挑战也很明显：首先是分布式的，那就会带来一定的技术复杂度，还有测试和运维的复杂性，服务管理成本等；数据、存储等数据一致性也有不少挑战；还需要较强的技术团队协作能力。这些一方面需要一套完整的微服务体系去保障（好在现在业界已有很多成熟的方案），另外一方面也和组织结构的设置和协作息息相关。

所以微服务适用的场景就是当你觉得利大于弊的时候啦~

特别篇：大体量下的日志管理怎么做的架构

划水看书写代码：大佬可否问一下大体量下的日志管理怎么做的架构包括一些dump级别业务级别等等的日志处理方式谢谢

不知道你说日志管理是应用框架的日志输出管理，还是类似 ELK 这种日志统一管理平台？

划水看书写代码：是应用框架日志输出管理

如果日志是落本地磁盘的，我们内部的一些实践是中间件统一采用一个日志框架（封装了slf4j），这样每个中间件和业务的日志都输出到了不同目录。Error 日志会输出到了单独的文件，方便采集和监控。不过这样做的话如果中间件很多，目录可能会有点多，你们实际过程中，可以自己权衡下，但最好业务和框架分开，Error和Info等分开。

划水看书写代码：那。。假设集群里某一台部署的是就版本从而引发了某些用户使用出现bug，如何快速定位相应日志呢。因为按我的理解，我们定位是要在同一个文件来进行查找，如果集群数量较多，那会不会引起查找难度增加，毕竟除了机器以为，日志是要按时打包的，尤其是在bug不明显的情况下。如果可以将集群中的日志整合，就可以通过时间节点来快速定位。

那就是不仅仅输出日志，还需要有类似 ELK 这种方案，将日志信息都采集到一个统一存储里面，再通过一些查询等能力来定位问题。

划水看书写代码：最近打算写个工具搞这个但是想问您要个建议
目前想法一种是脱离应用直接读取日志文件然后按照格式解析，之后将解析后的内容放到一个缓冲队列。用多路复用的方式将队列里的信息写到整合文件内。或者说交给es去管理。但是这种方式不一定会达成写大于读。而且读写文件的开销有点重复。另一种是重新写个日志管理方案，但是无法完全非侵入。让日志的出口不落实到文件，而是落实到缓存。

划水看书写代码：其次感觉这两种方案对于IO的消耗都比较大。

划水看书写代码：您觉得哪种更合适一些

传统一点就是应用写文件，Agent采集，再发到MQ，再写到存储。未来云原生方向肯定是往日志无盘化发展的，尽量让日志不落盘，直接通过数据流传到MQ和存储里，不过这个技术门槛还是比较高的。所以也看你们自己的投入吧。

由于篇幅原因，本期只摘录了部分问题，章耿也回答了很多其他的技术、非技术问题，欢迎去他的 AMA 下面交流技术哟，传送门。

往期 AMA