首先看它能不能满足当下业务需求,就像盖房子,得够住、布局合理。然后要看扩展性,业务发展了,它能不能轻松跟着 “长大”,别动不动就得推倒重来。再就是稳定性,得经得住日常使用,别总出故障。还有成本,投入别太高,不然公司吃不消。综合这些,能让业务顺顺当当跑,成本可控,就是好架构。
在考虑采用新技术的时候,架构师会先看看这个新技术能给业务带来多大的好处。比如,新技术能不能让系统速度更快、更安全或者更省钱。如果新技术能够带来这些关键优势,那它就比较有吸引力。然后,还要看看这个新技术是不是成熟。如果新技术刚出来,可能会有很多小毛病,就像刚上市的新手机可能会有软件不兼容之类的问题。所以,架构师会看看其他公司用这个技术的情况,有没有出现很多故障之类的。要是这个技术已经被很多同行用得很好,没有大问题,那采用它的风险就小一些。
31岁转型来得及。就像换个赛道跑步一样。 PHP经验已经是你的优势,这让你有了编程基础。如果想转型,先想好方向,比如转做前端、数据分析之类的。 你可以利用业余时间学习新技能,网上有很多免费或付费的课程能帮你。也可以参加一些线下的技术交流活动,认识新朋友,了解新领域的情况。 虽然31岁可能会有家庭等压力,但只要有决心,转型完全可行。
在小公司,啥都得干,从构思到写代码,随业务快速调整架构。中型公司的架构师沟通业务和技术,带小团队,关注技术选型。大公司架构师做战略规划,与多部门合作。从中小公司跳到大公司,要提升系统思维,从全局看问题;反正公司越大,架构师越难
我觉得这个问题我们用一辆新旧车打比方最合适了,假如你有一辆旧车(老旧架构)。 如果边造轮子边优化呢,就像是你这辆车有些零件坏了或者不太好使,你就一个一个地去换更好的零件来让车能接着好好开。这样做的好处是车子(系统)一直能跑,不会一下子就瘫在那儿,业务不会受到太大的影响。而且你在换零件(优化)的过程中,还能慢慢了解这辆车(架构)到底是咋回事,不至于手忙脚乱。不过呢,这也有个麻烦的地方,就是你换来换去,可能最后发现这些新零件和旧零件拼在一起,还是有点小毛病,而且可能因为一直修修补补,有些地方还是挺乱的。 要是直接重构,就像是你不要这辆旧车了,重新造一辆新车。这样做如果成功了,那车(系统)就会非常棒,很符合现在的需求,而且也很整齐干净。但是风险也大啊,你在造车(重构)的时候,车肯定是开不了的(系统可能得停摆一段时间),这对业务影响就很大。而且造车的时候你要是有个小失误,说不定整辆车都报废了(重构失败)。 所以到底是边造轮子边优化还是直接重构,得看这辆车(老旧架构)现在有多破。要是还能开,业务也还能勉强维持,那可以先边造轮子边优化;要是这辆车已经破得不行,老是出大问题,业务都快进行不下去了,那可能就得咬咬牙直接重构了。
我觉得吧!前端工程师想成为架构师得下些功夫。先拓宽技术面,学后端知识和数据库操作,全面了解软件系统架构。培养系统思维,参与大型项目,理解各模块协作,学会预测瓶颈。积累项目经验,参与复杂跨团队项目,优化流程。学习架构模式和设计原则,懂何时用哪种架构及遵循设计原则。还要锻炼领导和沟通能力,能清晰传达架构想法并听取他人意见。多参加技术分享会,提升表达能力同时学习新知识,一步步向架构师迈进。
我觉得这个得分情况,有的时候作为架构师需要验证自己想法的可行性,就好像你要造一座房子,在真正开始盖之前,你得先用简单的材料搭个小模型,看看你的设计思路能不能行得通。架构师在设计系统架构的时候也一样,他们会写一些简单的代码来看看自己想用的新技术或者新方案是不是真的能达到项目的要求,像看看新的数据库或者消息系统能不能很好地工作。但是也有不写代码的情况,比如说项目比较大,就像建造一个大城市一样,架构师可能主要是在画整个城市的规划图,规定不同区域之间怎么连接,制定一些标准,架构师可能主要是在设计整体架构,定一些接口和通信的规则,没那么多时间写具体的业务代码。
我觉得这个得分情况,有的时候作为架构师需要验证自己想法的可行性,就好像你要造一座房子,在真正开始盖之前,你得先用简单的材料搭个小模型,看看你的设计思路能不能行得通。架构师在设计系统架构的时候也一样,他们会写一些简单的代码来看看自己想用的新技术或者新方案是不是真的能达到项目的要求,像看看新的数据库或者消息系统能不能很好地工作。但是也有不写代码的情况,比如说项目比较大,就像建造一个大城市一样,架构师可能主要是在画整个城市的规划图,规定不同区域之间怎么连接,制定一些标准,架构师可能主要是在设计整体架构,定一些接口和通信的规则,没那么多时间写具体的业务代码。
《架构师的自我修炼:技术、架构和未来》,《软件架构师的 12 项修炼》:专注于介绍架构师所需的 12 项软技能,并详细讲解了如何修炼每一项技能,有助于开发者提升软技能,突破职业发展的瓶颈。《亿级流量网站架构核心技术》,详细讲解了网站架构中常见的各种技术,如缓存、队列、线程池、代理等,并配有核心代码,甚至包含 Nginx 的配置,可为架构师在实现大流量网站时提供实用的技术参考和代码示例
先把服务按功能拆好,每个服务就管一件事。放在云计算里的时候,用容器技术来放这些服务,流量多的时候可以快速复制增加服务。还要用负载均衡器,把流量均匀地分到各个服务实例上,这样流量大的时候也不怕。
缓存也很有用,像那些经常有人看但不怎么变的数据,就可以放在缓存里,下次看的时候直接拿,速度就快了。选通信协议很重要,要求性能特别高就用gRPC这种协议,简单的请求和响应场景用RESTful API就行。
要有服务发现工具,这样服务之间能方便地找到对方。而且服务之间的调用别太复杂,不然容易出问题、影响性能。