掘金 AMA：听蚂蚁金服高级技术专家-- 章耿谈微服务、架构、日志那些事

时间 2019-11-07

标签 ama 蚂蚁高级技术专家微服架构日志那些栏目系统架构繁體版

原文原文链接

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

提醒：本期Java、Spring、微服务主题的 AMA 还有不到 12 小时结束，欢迎前去提问，传送门：juejin.im/pin/5cebeab…缓存

关于章耿

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

社区小伙伴精选提问

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

您好，想问下你以为架构、技术、需求之间的关系应该是怎么样？对于架构设计而言，应该先知足目前的需求仍是将来技术？先谢谢您的回复框架

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

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

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

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

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

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

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

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

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

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

单一职责、高内聚低耦合

服务粒度适中

考虑团队结构

以业务模型切入

演进式拆分

避免环形依赖与双向依赖

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

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

请问，服务拆分后会出现微服务调用微服务的状况，致使效率很慢，接口的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 下面交流技术哟，传送门。