时长10:26大小8.38M
作者回复: 你先要建立对架构的框架性认知,了解各个架构概念的关系,这样你有框子装东西,有能力分辨接触到的架构内容都是属于哪方面。
然后浅到深往里面填东西。包括别人的架构分享,和公司里实际系统的设计。自己也有意识地去补一些知识短板,架构是实践性很强的技能,一方面你要了解背后的原因,另一方面你要多多去使用。
最简单地,你可以从学习GOF设计模式开始,然后对照JDK源码,了解都是怎么用的。设计模式你可以看作轻量级的架构设计。
作者回复: 看来你正在走向架构师的路上,有些自己的思考和困惑,这里有些建议供参考。
首先需要架构师思维,对架构有个正确的认知,一个方案设计都有哪些方面要考虑,比如业务的扩展复用,系统的高可用等等。
然后说下设计经验,架构是实践性很强的工作,它把你的知识变成技能,从虚到实。在缺乏一手经验的情况下,可以都看看别人的设计,但最好是能够有深入的细节,当时碰到什么问题,设计时有哪些可以选择的方案,怎么平衡和决策的。这样你就能深入明白,在场景和知识点之间建立强链接。
你这里说了很多技术组件,现在技术发展很快,一方面我们需要紧跟前沿的东西,不要落伍。但另一方面,技术点很多,全部深入掌握不现实。这怎么应对呢?
从开发的角度,学习技术先深度后广度,比如把rabbitMQ吃透,再学其他MQ,避免样样能,样样不精。
当你对技术了解一定程度,到了架构师程度,就要追求广度,先要大方向上了解,然后看具体点的深度。
架构设计时,你需要知道每类核心技术组件的典型应用方式,比如MQ,一般用于异步,系统解耦,流量削峰等用途,还有DB,缓存,MQ在不同业务场景下是怎么组合的,然后考虑具体的选用什么db,什么缓存和MQ组件。
然后每类组件,都有哪些具体实现,如果你对某个MQ很了解,其他的大致了解特性即可,不一定要深入细节,现在如果新推出一个MQ组件,你去了解它有什么新特性,这样实际也花不了太多时间。
作者回复: 是关于DDD与一致性分布式事务结合怎样设计更合理。
强的一致性分布式事务实现一般不推荐,实现太复杂,也严重影响性能。实践上有多种处理方式尽可能保证数据一致性。比如ebay经常用的本地消息,阿里的tcc,rocketmq支持的消息事务,或者调用出错后调用上个服务的取消接口,或者消息补偿等,你需要根据具体业务的特点选择落地方案,这里没有统一方案,有时候一致性没有我们想象的必须要做到。
第二个问题:
是关于网关的问题,我一般的都是使用自研netty。
a. 对于自定义服务聚合应该如何处理比较恰当.
不建议在网关层面做业务聚合,一般是构建单独的具体服务,网关做一些系统性功能,我有一讲是专门介绍1号店移动端网关的系统改造,你可以参考下。
b. 请求鉴权到达什么力度比较合适,如果权限比较复杂,如果使用jwt 在下游服务中该如何设计,有没有更好的方式。
c. 在使用k8s时,网关如何设计才能与与k8s的ingress更好的结合。
d.对于服务发现,如果在k8s中还是否有必要在网关中设计,产品应该如何选取?
网关一般针对外部请求,路由到内部服务,一般来说这个路由逻辑要比较灵活和复杂,比如解析url路径,确定路由到哪个内部服务,这个K8s内部服务的路由还是有区别。
第三个问题:
关于监控
日志:一般使用底层ES+K,收集用FileBeat推到Kafka,有没有比filebeat更好的产品选型或收集方式?
有没有别的,我不是特别清楚,我们也用filebeat,在.net环境,也踩到过占内存的坑。
监控:
一般需要监控的地方主要分为几大类,除了地址,我用了skywalking,还有预警,一般还需要考虑那些,如果上云平台的k8s,该如何搭配比较好?
监控这块,作为保证系统高可用的手段,专栏会有专门一篇实际案例介绍,到时有问题深入讨论。
第四个问题:
关于多租户SaaS和私有云,如何结合实现比较好,以及数据和升级该如何考量
核心问题是如何实现一套代码和数据结构,比如基于同样一套基础服务,方便应用和数据升级。
第五个问题:
关于分库分表,考量范围和如何设计才更合理?
这个专栏讲会有一篇文章专门介绍1号店的订单水平分库案例,相信你会找到答案。
作者回复: 这个问题有点大,首先看是业务方面问题还是系统稳定性方面问题。业务架构比较典型的有分布式,面向服务(soa和微服务),如果业务之间共性比较多,还要考虑服务平台化。技术架构主要是考虑高可用,高性能,系统能力能够水平扩展。具体落地时,要平衡预期效果,实现的复杂度和现有团队的水平,尽量接地气,设计好后,脑子里端到端过一遍,要避免过度设计,落不了地。
作者回复: 产品经理告诉你用户需要什么功能,架构师告诉开发怎么做,系统应该分成几个部分,怎么相互调用。
你想想一个大型建筑,为什么先需要进行架构设计,而不能直接让工人开干就明白。
架构师具体做什么,你听我下一讲就明白。
作者回复: 做事的方法论肯定重要,只是有时候我们得到的是模糊或部分正确的方法论,效果可能适得其反。
做架构师,首先要尽量要先了解系统全貌,能够站在全局的角度考虑问题,当然这个是一步步来的。建议你平时多了解现有业务和系统实现,找出问题。
作者回复: 谢谢自家兄弟,我把你的留言也送上去。
作者回复: 你好,欢迎一起讨论分享。
对于现有业务系统了解,一般可以遵循 以下过程。
学习架构文档->界面功能操作->数据库表结构了解->读代码->实际用户聊 等方式。
对于你这种情况,你可以先了解系统操作说明书,包括看下操作界面,然后结合表结构了解系统设计。
这里关键还不是深入单个业务系统,了解各个系统的相互关系更重要,这样可以总体上识别问题和把握系统设计。
技术跟踪方面,你写写POC,读读源码这样很好啊,其他的,你可以参加一些技术大会,了解大厂都在用什么技术,还有一些好的技术公众号和微信群,也会有大量前沿技术分享。如果有很系统地技术文章介绍,也可以深入研读下,了解它的核心机制,极客时间有些内容还不错。
你目前这样甲方角色,个人工作经验也很丰富了,我个人觉得业务和技术比重7:3差不多,仅供参考。
作者回复: 需要比较深入的认识,精通不需要,比如tcp,udp,进程线程知识要有,具体协议细节不一定要了解很透彻
作者回复: 中台是一种架构理念,目标是实现企业级能力复用,这个能力首先是业务能力,业务能力的复用高于技术能力复用。严格的讲,它和微服务架构一样,是属于应用架构,即系统内部关系是如何组织的。
作者回复: 听完这个专栏,你就有思路,知道如何去做了
作者回复: EA是更高层面的架构,这个一般是老板要思考的,比较虚,架构师不会涉及这个层面。架构师核心的职责是负责架构设计,已经在研发过程中,跟进架构落地,解决疑难问题,当然实际工作中,职责边界没有这么清。你说的这几部分,开发团队分工,架构管理,团队IT能力建设这几块会涉及一些,而开发策略和版本管理更多研发团队负责。
作者回复: 上得厅堂,下得厨房, 又高端又接地气 :)
作者回复: 你看下专栏的01篇,有专门的解释
作者回复: 为什么是前架构,转行了? 说说呗,让大家知道架构师还有更多出路。