38 | 架构师应该如何判断技术演进的方向？

成熟的架构演进和案例当然是可以借鉴的，相信有不少架构师都读过淘宝技术十年。但是如果说参照他人的架构演进，将自己的架构一步设计到位我觉得这本身就是个伪命题。 为什么？ 1.首先淘宝自己的架构是在持续的演进中的，可能技术的变革、业务的创新、硬件性能的提升等都会迫使架构产生变化，没有所谓最优解。 2.技术和架构是不能脱离业务来谈的，否则我们怎么去衡量它们的价值和收益呢。世界上没有两片相同的叶子，淘宝的业务在结构、体量和形态上往往和很多企业有很大的差异。 3.针对于架构实践，另一个不能避免问题就是，管理和成本。不同的架构设计解决问题的广度和深度不同，相应的带来的管理复杂度和人力物力的成本也不同。 那具体该怎么做呢？我的理解是 1.结合激进、保守、跟风，作为架构的实践者，必须及时跟进新的技术体系，同时需要慎重考虑引入新的内容，要想清楚它的必要性、能在短期带来的什么收益、能解决什么问题，同时还需要以观察者的角度来看业界大厂的实践，同时思考他们为什么要这么做，对于我们以后改进设计很有帮助 2.对于架构演进来说是有成本的，在准备改变之前还要想明白的一个事就是这么做的成本是什么，会给我们带来什么样的收益，当前的团队规模是否能稳定驾驭

我感觉要分情况讨论,但是本质上还是要符合 "合适" "简单" "演进" 原则的. 假设淘宝目前的架构是 100 分. A : 假设是一个量级也是很大的电商 (比如苏宁,京东) : 初始的阶段和要求就很高 ,可能一上线就有大量用户 , 建议参考淘宝的架构 , 至少达到60分. 不用一步到位, 但是要有大部分基础功能 (比如肯定要有缓存, 要服务化, 肯定要上docker , 肯定要有基础的微服务组件, 订单系统 , 用户系统至少先做的能够支持一段时间的用户增长 ; 但是可以不用自研, 先使用开源 ) B : 假设是一个量级较小的小网站. 这个就不建议一步到位, 没人没钱搞这个; 能达到淘宝的20分 可能都够用. 可以根据人力,时间,机器等资源 . 解决当前的最大矛盾: 可能就是先上一版初版, 效果好后续慢慢演进 . 效果不好没有用户, 那以后人都没有了也就不用演进了. 😂

最近遇到一个现实的架构设计，本来一个业务不多系统却要上微服务架构，项目经理解释说不弄点流行技术，公司就少投钱。这就是现实啊😄

请问下画架构图用什么软件的？

觉得还是应该按演进的思想来，先根据业务发展阶段选择合适的架构，业界的案例可以作为演进的方向

选择什么样的架构和看病一样要对症下药。 首先要预估业务规模和系统1.0上线后，系统的并发量，以略高于预估的并发量来设计，否则，系统一上线，用户来访问，分分钟挂掉，对业务是莫大的损失，又丢用户又丢技术人员的脸。 系统上线后，关注系统的压力，并探讨用户数到下一个量级，架构和技术要如何支撑为课题，综合技术团队的技术水平和技术团队规模能驾驭的架构来做选择。 涉及到新技术的，要尽早去学习试错，以期用时能淡定从容应对。

像浏览器这样的产品，使用规模还是会影响用户选择的，假如我有一个更好的浏览器ud浏览器 但如果周边的人都用uc，网上也推荐用uc，那可能用户就选择uc了，这个还是“规模”作用啊 还有打车软件，比如我自己不但提供软件可以打车，而且自己也提供车，用户会因为我提供的车更专业选择我的，也会因为这个软件的“规模”选择我的 也就是说该如何严格确定，一个东西到底是产品，还是服务呢？

有成熟的架构参考。在一定程度上，可以预知以后系统变大后，可能要做一些什么,还有大体的逻辑结构会怎么样，因为这是通过检验的。但是业务上并不完全一致的情况下和体量不一样的情况下，详细的设计还是需要结合实际去做的。

一个企业的技术架构是随着业务发展逐渐演化生长出来的 绝不可能照抄别人就可以。就像每个人都是独一无二的，拥有不一样的经历和人生。

之前团队内的架构师倡导的一句话就是，脱离业务的架构就是耍流氓