开篇词 | 想吃透架构？你得看看真实、接地气的架构案例
为什么开发人员要学习架构？
一、无架构，不系统
二、拓展你的职业发展空间
如何学习架构？
我是如何规划这个课程的？
写在最后
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
王庆友的专栏《我是如何规划这个课程的？》旨在为读者提供全新的架构学习体验。文章首先强调了架构设计在系统和个人发展中的重要性，以及成为优秀架构师的挑战和必备条件。王庆友指出，学习架构需要跳出小模块，从系统整体和业务角度考虑问题，并在各方面做好平衡。他承诺通过专栏分享实际项目的架构经验和提供大量接地气的案例，帮助读者快速掌握架构的核心内容。文章还介绍了课程的内容规划，包括业务架构和技术架构两大部分，以及每个部分的具体内容和案例。最后，王庆友鼓励读者多思考、多交流、多实践，并欢迎读者在课程中提出问题，承诺及时给予反馈。整体而言，这篇文章为读者提供了一个清晰的认知框架，让他们能够系统地学习架构，并在实际工作中应用所学知识。
2020-02-1923人觉得很赞给文章提建议
《架构实战案例解析》，新⼈⾸单¥59
全部留言(35)
- 最新
- 精选
250ZH置顶成为好的架构师，需要对各种组件掌握到什么程度呢？知晓大概原理还是要清楚比较细节的实现方法。先深度后广度，那深度要多深，广度要多广?作者回复: 全部都了解细节这不大现实，有些要了解细节，比如微服务框架，rpc通信，最好能深入看下开源组件的源码。掌握一部分组件后，其他的组件知道原理和特性后，大概你也知道内部实现机制。 Soa，db，缓存，MQ这四大组件的特性你肯定都比较清楚，知道每类具体实现的优劣点和适用场景，这样架构设计时才能比较好的选型。
2020-03-165
粗线条Jackie置顶很荣幸能够拜读到王老师多年的经验心得，并有机会与您进行交流。老师的质朴的风格，很有金庸小说中大侠的"重剑无锋，大巧不工"的厚重感，十分期待您的后续新作。 做为一个IT从业超15年的"老兵"，从传统企业应用开发一路走来，经过产品研发，项目管理，目前在一家外资背景的new entrant快消零售公司做数字解决方案架构师。平时工作更多是梳理和打磨企业内部应用资源整合，以及摸索微信/电商平台新玩法用于更好的支持市场营销活动，有时也会兼顾一些外部IT供应商的项目管理工作。 老师在课程中提到的"业务架构"和"技术架构"话题，我各有一些疑惑想与您探讨，希望能指点一二： 1. "业务架构"部分：这部分目前是我投放精力比较多的部分，对于空降的项目管理者/企业架构师，需要尽快对企业内部各烟囱式业务系统(含历史Legacy System)有一个全局的了解，但由于一些历史的原因，很多系统的原始资料非常匮乏(有此前供应商要求不严格和部门壁垒等因素)，除了借助行政层级施压，可有方法快速破局？ 2."技术架构"部分：虽然自己是技术出身，也有过多年行业Top IT厂商和BAT大厂的从业经历，但八年前跳槽甲方后，更多是供应商交付及项目管理，对于行业业务的关注多过技术。对于技术的"保鲜"，我目前采取多听取供应商招投标解决方案，以及闲暇时间写一些主流框架的整合POC原型(SpringBoot及Netflix架构体系)，但感觉还不是很系统。请教老师，是如何跟进技术的发展趋势，保持个人技术的成长，以及平衡业务与技术比重分配的呢？作者回复: 你好，欢迎一起讨论分享。 对于现有业务系统了解，一般可以遵循 以下过程。 学习架构文档->界面功能操作->数据库表结构了解->读代码->实际用户聊 等方式。 对于你这种情况，你可以先了解系统操作说明书，包括看下操作界面，然后结合表结构了解系统设计。 这里关键还不是深入单个业务系统，了解各个系统的相互关系更重要，这样可以总体上识别问题和把握系统设计。 技术跟踪方面，你写写POC，读读源码这样很好啊，其他的，你可以参加一些技术大会，了解大厂都在用什么技术，还有一些好的技术公众号和微信群，也会有大量前沿技术分享。如果有很系统地技术文章介绍，也可以深入研读下，了解它的核心机制，极客时间有些内容还不错。 你目前这样甲方角色，个人工作经验也很丰富了，我个人觉得业务和技术比重7:3差不多，仅供参考。
2020-02-254
约书亚置顶您在文章开头提到的，当前众多架构相关的内容，所具有的通病，真是一针见血。 我工作13年，做所谓“架构工作” 4，5年的时间，我的困惑就是觉得自己越来越不懂如何做架构，也不懂什么是架构师了。 首先是，架构师要学那么多知识，学习的边界是什么？哪怕有个模糊的边界。 其次，我们要如何看待架构中的方法论？方法论似乎在软件行业里特别不容易落地，以至于我认识的几个大佬都不太重视。但有不少人处于反面，认为方法论很重要，要贯穿整个研发周期，但当我和他们细聊时发现，他们对此方法论的理解还都不统一，应用起来也不遵守规则。那方法论不就仅仅起到一种团队内规章规范的作用了么？ 最后，我一直觉得架构师的工作就是发现问题，解决问题，预防问题。但很多时候我们对需求，对系统压根没法获得一个清晰的认识，这也就发现不了问题。这时除了“套用已有的经验先完成一版简单的设计，之后根据反馈进行演进”这种方法外，还有什么积极些的办法么？作者回复: 做事的方法论肯定重要，只是有时候我们得到的是模糊或部分正确的方法论，效果可能适得其反。 做架构师，首先要尽量要先了解系统全貌，能够站在全局的角度考虑问题，当然这个是一步步来的。建议你平时多了解现有业务和系统实现，找出问题。
2020-02-22
Geek_kevin置顶王老师您好，请问我们这个课程谈的架构和企业架构EA有没有关联？ 是否会涉及架构师的角色和定位？对于架构师来讲，会涉及开发团队分工，开发策略，版本管理，架构管理，以及团队IT能力建设相关方面的内容吗？作者回复: EA是更高层面的架构，这个一般是老板要思考的，比较虚，架构师不会涉及这个层面。架构师核心的职责是负责架构设计，已经在研发过程中，跟进架构落地，解决疑难问题，当然实际工作中，职责边界没有这么清。你说的这几部分，开发团队分工，架构管理，团队IT能力建设这几块会涉及一些，而开发策略和版本管理更多研发团队负责。
2020-02-22
偏偏置顶王老师，你好，很高兴能有机会与您交谈，我架构时间不长，最近有一些困惑，刚听了一次您的课，感觉很贴切，有几个问题希望老师能有时间给出点建议。 第一个问题： 是关于DDD与一致性分布式事务结合怎样设计更合理。 第二个问题： 是关于网关的问题，我一般的都是使用自研netty。 a. 对于自定义服务聚合应该如何处理比较恰当. b. 请求鉴权到达什么力度比较合适，如果权限比较复杂，如果使用jwt 在下游服务中该如何设计，有没有更好的方式。 c. 在使用k8s时，网关如何设计才能与与k8s的ingress更好的结合。 d.对于服务发现，如果在k8s中还是否有必要在网关中设计，产品应该如何选取？ 第三个问题： 关于监控 日志：一般使用底层ES+K，收集用FileBeat推到Kafka，有没有比filebeat更好的产品选型或收集方式？ 监控： 一般需要监控的地方主要分为几大类，除了地址，我用了skywalking，还有预警，一般还需要考虑那些，如果上云平台的k8s，该如何搭配比较好？ 第四个问题： 关于多租户SaaS和私有云，如何结合实现比较好，以及数据和升级该如何考量 第五个问题： 关于分库分表，考量范围和如何设计才更合理？作者回复: 是关于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号店的订单水平分库案例，相信你会找到答案。
2020-02-21214
李青置顶老师我一直不知道什么是软件架构，架构师在软件开发做了什么作者回复: 产品经理告诉你用户需要什么功能，架构师告诉开发怎么做，系统应该分成几个部分，怎么相互调用。 你想想一个大型建筑，为什么先需要进行架构设计，而不能直接让工人开干就明白。 架构师具体做什么，你听我下一讲就明白。
2020-02-208
唐高为置顶我刚考过了软考的系统架构师，也学习完了极客时间的《从0开始学架构》，感觉还是挺虚，可能还是缺乏大型系统的设计经验。除了缺乏经验以外，我觉得还有一点也很关键，那就是缺乏对各种架构组件的认识，比如 MongoDB、ElasticSearch、Kafaka、K8s、Hadoop 等等。我觉得要学好架构，除了架构师思维外，还得紧跟前沿技术，了解各种工具的特点，这样才能在设计出更加合适的系统框架。作者回复: 看来你正在走向架构师的路上，有些自己的思考和困惑，这里有些建议供参考。 首先需要架构师思维，对架构有个正确的认知，一个方案设计都有哪些方面要考虑，比如业务的扩展复用，系统的高可用等等。 然后说下设计经验，架构是实践性很强的工作，它把你的知识变成技能，从虚到实。在缺乏一手经验的情况下，可以都看看别人的设计，但最好是能够有深入的细节，当时碰到什么问题，设计时有哪些可以选择的方案，怎么平衡和决策的。这样你就能深入明白，在场景和知识点之间建立强链接。 你这里说了很多技术组件，现在技术发展很快，一方面我们需要紧跟前沿的东西，不要落伍。但另一方面，技术点很多，全部深入掌握不现实。这怎么应对呢？ 从开发的角度，学习技术先深度后广度，比如把rabbitMQ吃透，再学其他MQ，避免样样能，样样不精。 当你对技术了解一定程度，到了架构师程度，就要追求广度，先要大方向上了解，然后看具体点的深度。 架构设计时，你需要知道每类核心技术组件的典型应用方式，比如MQ，一般用于异步，系统解耦，流量削峰等用途，还有DB，缓存，MQ在不同业务场景下是怎么组合的，然后考虑具体的选用什么db，什么缓存和MQ组件。 然后每类组件，都有哪些具体实现，如果你对某个MQ很了解，其他的大致了解特性即可，不一定要深入细节，现在如果新推出一个MQ组件，你去了解它有什么新特性，这样实际也花不了太多时间。
2020-02-20635
sakyawang置顶请问老师，架构选型一般要从哪几个方面入手进行整理比对呀作者回复: 这个问题有点大，首先看是业务方面问题还是系统稳定性方面问题。业务架构比较典型的有分布式，面向服务（soa和微服务），如果业务之间共性比较多，还要考虑服务平台化。技术架构主要是考虑高可用，高性能，系统能力能够水平扩展。具体落地时，要平衡预期效果，实现的复杂度和现有团队的水平，尽量接地气，设计好后，脑子里端到端过一遍，要避免过度设计，落不了地。
2020-02-1911
学要有所用置顶我之前给老师留言过，不过没得到解答，希望老师这次有空解答下，我在极客时间上买过一些课程，而且讲的不错，但碍于自身基础的不足导致学习效果不佳，而这种不限于某种技术又较为艰深对综合能力也提出更高要求的架构，该怎么学习？又该怎么学好呢？希望老师给些建议！作者回复: 你先要建立对架构的框架性认知，了解各个架构概念的关系，这样你有框子装东西，有能力分辨接触到的架构内容都是属于哪方面。 然后浅到深往里面填东西。包括别人的架构分享，和公司里实际系统的设计。自己也有意识地去补一些知识短板，架构是实践性很强的技能，一方面你要了解背后的原因，另一方面你要多多去使用。 最简单地，你可以从学习GOF设计模式开始，然后对照JDK源码，了解都是怎么用的。设计模式你可以看作轻量级的架构设计。
2020-02-1921
cricket1981中台概念是属于业务架构吗？作者回复: 中台是一种架构理念，目标是实现企业级能力复用，这个能力首先是业务能力，业务能力的复用高于技术能力复用。严格的讲，它和微服务架构一样，是属于应用架构，即系统内部关系是如何组织的。
2020-02-235
