转载

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

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

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

关于 章耿

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

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

社区小伙伴精选提问

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

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

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

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

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

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

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

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

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

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

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

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

  1. 单一职责、高内聚低耦合
  2. 服务粒度适中
  3. 考虑团队结构
  4. 以业务模型切入
  5. 演进式拆分
  6. 避免环形依赖与双向依赖

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

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

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

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

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

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

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

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

微服务强依赖怎么解决

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

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

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

微服务带来的好处很多啊,例如:

  • 业务逻辑更加内聚,功能易于独立的开发维护
  • 松耦合,开发部署等都独立,方便快速迭代
  • 可以跨不同的语言、技术栈
  • 可以部署在低配的环境上
  • 等等

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

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

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

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

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

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

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

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

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

划水看书写代码:最近打算写个工具搞这个 但是想问您要个建议

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

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

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

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

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

原文  https://juejin.im/post/5cef580251882567697f9997
正文到此结束
Loading...