❶ 如何成为软件架构师
架构师首先必须具有丰富的开发经验,是个技术主管。因为他必须清楚什么是可以实现的,实现的方式有哪些,相应的难度怎么样,实现出来的系统面对需求变化的适应性等一系列指标。另外,需要对面向过程、面向对象、面向服务等设计理念有深刻的理解,可以快速的察觉出实现中的问题并提出相应的改进(重构)方案(也就是通常说的反模式)。这些都需要长期的开发实践才能真正的体会到,单从书本上很难领会到,就算当时理解了也不一定能融会到实践中去。在技术能力上,软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识,包括进程内通信(对象访问、函数调用、数据交换、线程同步等)以及进程外(包括跨计算机)的通信(如RMI、DCOM、Web Service)。在WEB应用大行其道的今天,开发者往往对服务器间的通信关注的比较多,而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石,它是架构设计中的鸟瞰视图;而进程内的通信是模块实现的骨架,它是基石的基石。如果具体到一个基于.Net企业级架构设计,首先需要的是语言级别的认识,包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识,包括ASP.NET Web Service、.NET Remoting、企业服务组件等。总之,丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去,给代码编写人员带来实实在在的可行性。其次,具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力,可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事,一厢情愿的保留接口在需求变化中的命中率非常低。也就是说,在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用,因为需求的变化并没有按照预想的方向进行,到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。再次,架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围,包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程,沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊,我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱,让系统构建过程可以有条理的高效进行。另外,对人的关注还表现在对团队成员的素质判断上,比如哪些开发人员对哪些技术更熟悉,或者哪些开发人员容易拖进度等。只有合理的使用人力资源,让合适的人做合适的事情才能让整个软件过程更加高效。架构师应时刻注意新软件设计和开发方面的发展情况,并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级,软件架构师需要吸收这些新技术新知识,并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行,不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术,而且它们在推广自己的解决方案的时候往往是以自己的产品为中心,容易给人错觉。比如数据库,往往让人觉得它什么都能做,只要有了它其它什么都不重要了。但事实上并不是如此,对于小型应用可以将许多业务逻辑用script的方式放入数据库中,但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断,包括横向的比较和纵向的比较,最后得出一些性能、可移植性以及可升级等指标。另外,新入行的开发人员往往关心新技术动向而忽略了技术的历史,而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。
❷ 架构师成长之路:到底什么是架构设计该如何理解架构设计
架构设计是一个大家耳熟能详的词,基本都烂大街了。
可是,到底什么是架构设计呢?估计很多人就回答不上来了。
下面就来详细聊聊什么是架构设计,以及对架构设计的一些基本认识。
软件架构设计指的是:对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列活动,架构设计的产物就是一个系统的架构。
架构设计实际上是一个过程,围绕着软件系统,对它的架构,进行定义、文档编写、维护和改进、并验证实现等,把这一系列活动组合起来,就是我们所说的架构设计。
架构设计的产物,也就是结果,就是架构,这也是架构和架构设计的关系。
架构设计是一门科学,这个已经是业界共识。但是作为一门科学来讲,它一定要有它自己的基础理论,基础方法,也会有一些实现的方法论。
架构设计作为一门科学来说,还很不成熟。目前架构设计的基础理论还不是很完善,方法论上,更是百花齐放,大家都还处于一个探索的阶段。
从科学上来讲,架构设计主要关注架构设计过程当中的:技术、流程、资源、方法;以及如何去完善并改进架构。
刚讲到架构设计这门科学还很不成熟,再加上技术领域更新很快,新技术、新思想、新方法 层出不穷。
我们总会面对很多新兴的、没有先例的系统,可能会应用新的框架、新的技术、新的解决方案来实现系统。
因此,做架构设计的时候,是需要一定的创造力的。当然,艺术细胞缺乏的人员也不用太担心,架构设计上还是有很多是有章可循的,多半是在已有的架构体系上去做一些微调,微创新,并不是完全从零开始。
架构设计不是一蹴而就的,通常也是由粗到精,刚开始,可能只有一个粗略的架构设计,然后不断迭代和演化,逐步推进,去完善和细化,这样的过程。
这个可能有些人不太理解,认为说,软功过程里面,不是有专门的概要设计、详细设计的时间吗?架构设计不就是在这些设计阶段去完成的吗?做完设计了,把文档发下去,不就没事了吗?
有些公司也是这么干的,实际上这是有问题的。
架构设计会跨越软工的完整流程,对于一些大型的或者是重要的项目,可能立项期间,架构师就要参与,做一些粗略的架构规划,有两个基本的原因:
1:能不能做得了这件事
2:按照粗略的架构规划做下去,大致的成本会有多大
立项的时候,就要去考虑你的成本,风险和投资收益。
也就是说,立项的时候,架构师可能就需要参与,那就更不用说需求阶段、设计阶段了,架构师是肯定要参与的,前面讲需求分析的时候已经讲过了,这里就不多啰嗦。
到了编码阶段,有些人可能认为架构师是不参与的,这是不对的。架构师需要参与,只是参与的少一些,主要是一些重点、难点的地方,或者是公共基础功能,由架构师来实现。
另外在编码阶段,架构师还有一个重要的任务,就是确保开发人员按照架构设计去实现,不要乱做。这就需要两个基本的方式,一个是架构师要把架构设计的成果,跟开发人员讲解清楚,并不断沟通;另外一个就是要不断检查,Review,以确保架构设计的落地实现不出大的偏差。
后面的测试、部署、运维等阶段,架构师要做一些技术咨询,或者是技术指导的工作。架构设计里面,本来就包含部署架构的设计,因此,架构师也会参与这些阶段,只是参与的少一些。
总之,架构设计需要关注所有利益相关者的要求,参与系统设计实现的所有人员,也都是系统的利益相关者,自然而然的,架构设计就需要贯穿软工的整个流程了。
一个系统,要关注的方方面面是很多的,利益相关者也很多,大家关注点各有不同。
这就意味着,在做架构设计的时候,需要不断去做决策,在众多关注点中去寻求平衡,所以有人说,做架构设计,就是一种玩平衡的艺术。
比如:从技术上讲,A+B的方式是性能最高的;但是从成本上来看,A+C是最合适的。可能最后综合权衡后,B+C是各方都能接受的方案。
这种需要考虑的平衡很多,比如:技术和成本的平衡;方案适用性年限的平衡,是满足1-3年就够了,还是要考虑8-10年;技术方案和当前开发人员技能的平衡;性能和成本的平衡等等,非常多。
架构设计是一个过程,需要在这个过程中,不断去考虑各利益相关者的要求,并不断折中平衡,因此架构设计的产物,也就是架构,自然就是各方利益相关者的共识了。
要做出好的架构设计,经验是不可或缺的,不会每次都是从零开始。
比如以前做过类似的系统;或者是学习到的一些好的架构模式,设计模式,一些现成的组件;或者是一些开源的框架等等的,这些我们都可以看成是可重用的资源。
我们做架构设计的时候,需要不断去积累这样子的可重用资源,形成自己的工具箱。这样当我们在做一个系统的架构设计的时候,就有了很多备用的工具或手段。
有了这些经验和资源的积累,会使得新系统的架构设计变得更容易。
❸ 如何成为软件架构师
【原创回答】我本人是一名软件架构师,这个问题非常大,不太好回答。我总结一下,软件架构师的能力大概分为三个方面:1.技术,这个应该没悬念,如果没有过硬的开发技术,就不要期望做架构师了;设计模式,系统模式,架构模型,系统理论,甚至编程语言,算法,操作系统,网络,数据库,都需要有扎实的掌握。 2.是业务知识,也即领域知识。软件架构师实际上是把业务需求落实成开发蓝图的总设计师,如果你对业务一窍不通,空有一身技术也只能望业务兴叹。3.就是沟通表达的能力,架构师需要推进自己的架构设计理念给开发团队,所以也需要这方面的能力,当然最重要的还是前两部分的能力。
❹ 如何学好软件系统架构
学好软件架构,主要在于多做大型复杂需求,在做需求中体会别人设计的架构的优缺点,最后尝试优化这个架构,这是学好架构的不二法门。
架构不是看书听课学得会的。面对同一行字同一句话,有实践和没实践的人,完全是不同的理解,没实践的人甚至连问题都问不出来。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。
❺ 软件架构的设计
为了讨论和分析软件构架,必须首先定义构架表示方式,即描述构架重要方面的方式。在 Rational Unified Process 中,软件构架文档记录有这种描述。
架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言,如Wright (由卡内基梅隆大学开发),Acme (由卡内基梅隆大学开发),C2 (由UCI开发), Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 构架
构架视图的图形描述称为构架设计图。对于以上描述的各种视图,设计图由以下统一建模语言图组成 [UML99]:
逻辑视图:类图、状态图和对象图。
进程视图:类图与对象图(包括任务 - 进程与线程)。
实施视图:构件图。
部署视图:配置图。
用例视图:用例图描述用例、主角和普通设计类;顺序图描述设计对象及其协作关系。 软件设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的重要决定的作出。
这样的人就是所谓的架构师(Architect)。在很多公司中,架构师不是一个专门的和正式的职务。通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作。在一个部门中,最有经验的项目经理会负责一些架构方面的工作。
但是,越来越多的公司体会到架构工作的重要性,并且在不同的组织层次上设置专门的架构师位置,由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
❻ 软件架构的设计方法
在软件中架构模式主要有两种,一种是c/s模式,一种是b/s模式,这里一起探讨下b/s架构怎么设计,希望对大家有帮助,请帮忙点赞
第一步
b/s模式是浏览器--服务器的模式,这中模式比c/s 客户端-服务端的模式好,有点较多:
b/s模式可以随时更新,用户不用频繁的升级客户端
第二步
架构b/s模式,主要是服务端的架设,一般情况浏览量比较小的时候只需要一台服务器
第三步
如果网页需要与记录客户的一些信息,比如资料、订单之类,需要涉及到数据库,需要在服务器端增减数据库
第四步
当客户较多时,需要做负载均衡,需要F5、或者ngxin:
第五步
当数据库压力比较大的时候,需要建立数据库的集群:
❼ 架构类型以及软件架构逻辑详解
架构类型:分布式、SOA架构、单体式。
分布式架构
分布式应用架构中,相互独立,代码独立开发,独立部署,通过API接口互相通信。通讯协议一般使用HTTP,数据格式是JSON(是一种轻量级的数据交换格式),应用集成方式比较简化。
优点: 应用内部高内聚,独立开发、测试和部署,应用之间松耦合,业务边界清晰,业务依赖明确,支持大项目并行开发。
缺点: API接口需求变化,应用就需要重新部署,通信可靠性和数据的封装性相对于进程内调用比较差。
SOA架构[现在也流程SAAS服务模式架构也称云架构]
SOA也是分布式应用架构一种。
SOA架构提供配套的服务治理,包括服务注册、服务路由、服务授权、服务降级、服务监控等等。
SOA架构既体现业务的拆分,又体现业务的整合,更多地从业务整体上考虑系统拆分。
优点:以服务层为主,聚焦核心业务,同时以提供整个系统共享,服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署,服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和资源高效利用。
缺点:系统依赖复杂,给开发/测试/部署带来不便,分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决。
单体式应用
系统只有一个应用、打包成一个应用;部署在一台机器;在一个DB里存储数据.
单体式应用采用分层架构,一般为表示层、业务层、数据访问层、DB层,表示层负责用户体验,业务层负责业务逻辑,数据访问层负责DB层的数据存取
优点:开发、编译、调试一站式、一个应用程序包含所有功能点,容易测试和部署
缺点:系统逐渐庞大时,代码复杂度高,难以维护,应用扩展水平低,业务和模块职责区分不清晰。
软件架构
一、 微服务架构
微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。
每一个服务就是一个独立的部署单元(separately deployed unit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。
微服务架构分成三种实现模式。
RESTful API 模式 :服务通过 API 提供,云服务就属于这一类
RESTful 应用模式 :服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部
集中消息模式 :采用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群
优点
扩展性好,各个服务之间低耦合
容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
易于测试,可以单独测试每一个服务
缺点
由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。
一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。
分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。
二、 事件驱动架构
事件(event)是状态发生变化时,软件发出的通知。
事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。
事件队列(event queue):接收事件的入口。
分发器(event mediator):将不同的事件分发到不同的业务逻辑单元。
事件通道(event channel):分发器与处理器之间的联系渠道。
事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作
对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。
优点
分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好;适用性广,各种类型的项目都可以用;性能较好,因为事件的异步本质,软件不易产生堵塞;事件处理器可以独立地加载和卸载,容易部署
缺点
涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚分布式和异步特性导致这个架构较难测试。
三、分层架构。
分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。
这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。
虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。
表现层(presentation):用户界面,负责视觉和用户互动。
业务层(business):实现业务逻辑。
持久层(persistence):提供数据,SQL 语句就放在这一层。
数据库(database) :保存数据。
有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。
用户的请求将依次通过这四层的处理,不能跳过其中任何一层。
优点
1、结构简单,容易理解和开发。
2、不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
3、每一层都可以独立测试,其他层的接口通过模拟解决
缺点
1、一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
2、部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
软件升级时,可能需要整个服务暂停
3、扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难。
五、 微核架构。
微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。
内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。
优点
1、良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
2、功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
3、可定制性高,适应不同的开发需要
4、可以渐进式地开发,逐步增加功能
缺点
1、扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
2、开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制。
五、 云架构。
云结构(cloud architecture)主要解决扩展性和并发的问题,是最容易扩展的架构。
它的高扩展性,主要原因是没使用中央数据库,而是把数据都复制到内存中,变成可复制的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里,最好要进行数据持久化。
这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。
处理单元:实现业务逻辑
虚拟中间件:负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
❽ 北大青鸟设计培训:如何成为一名软件架构师
你必须不断寻求改善。
这里有一些很不错的书籍,可以提升你的技能:每一个软件架构师都应该知道的97件事企业应用架构模式C#中的敏捷原则、模式与实践企业集成模式Javascript:最精彩的部分修改代码的艺术领域驱动设计企业架构战略设计模式目标SOA设计模式SOA服务设计原则每一到两年学习一门新的编程语言。
选择一个重点领域,佳音北大青鸟http://www.kmbdqn.cn/建议尽可能对技术有一个高层次的理解。
针对你的重点领域,开始写博客,并继续扩大你的知识面,在你的重点领域中成为专家。
尝试不同的技术、编程语言、设计模式、架构等。
向你的听众介绍技术,并努力让每个听众都能理解。
❾ 如何成为一个架构师
1、技术能力
技术能力,不用置疑肯定是最重要的。技术能力弱的架构不是一个好架构。所以,你需要知道所有主流技术的基本原理、应用场景,及快速解决问题的能力。所以,架构师必须要有见识,所需知识面肯定是要不断拓展的。
你需要清楚在什么样的场景用什么样的技术比较合适,并知道可能存在什么样的风险。来了需求,你脑袋是空的,不知道用什么技术这是最可怕的。
2、架构能力
这个可以表现为抽象能力、整体规划能力、及设计能力。你需要照在业务的角度进行系统分解、技术选型、架构搭建,以及规范制定。架构出来了至少可以满足最近的发展,或者可以很方便对现有架构进行扩容。
3、沟通能力
作为一个优秀的架构师,你需要清楚的知道客户的需求,需要不断和需求人员进行沟通,以达到客户真正的目的。不论是不是架构师,任何一个职场人,提高自己的沟通表达能力无疑是不可或缺的。
系统架构师的主要功能包括:
1、系统架构师是软件项目的总体设计师,是软件组织新产品的开发与集成、新技术体系的构建者。
2、系统架构师是在技术上对所有重要事情做出决定的人(系统架构师在整个软件开发过程中都起着重要作用,并随着开发进程的推进而其职责或关注点不断地变化)。
3、需求阶段,软件架构师负责理解和管理非功能性系统需求,比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。
4、设计阶段,架构师负责对整个软件架构、关键构件、接口的设计。协助系统分析师完成《系统概要设计说明书》。
5、编码阶段,架构师则成为程序员的顾问,并且经常性地要举行一些技术研讨会、技术培训班等。
6、测试及实施阶段,随着软件开始测试、集成和交付,集成和测试支持将成为软件架构师的工作重点。
❿ 怎么成为一个软件架构师
架构师是一个充满挑战的职业,知识面的宽窄往往决定着一个架构师的架构能力,所以在这一点上我比较赞成你的学习方式,就是要阅读大量的技术书籍,但我希望你不要仅限于软件相关的书籍,经常泡技术论坛,一方面可以结交朋友,一方面可以增加自己的知识面。
公司的大小往往决定了所做的项目规模,一般的大项目不太可能直接总包给小公司去做,但这并不妨碍小公司可以分包到大项目的一部分。在做小项目的同时也可以积累丰富的经验,我自己就是一个这样的例子。
我在小公司混迹了5年多,其中也偶尔有1两个大公司,比如大唐电信,但是基本上都是小公司,从基层的程序要到公司的开发总监都做过,甚至自己还设计过包括LED显示屏,密码键盘在内的收费系统,自己联系厂家OEM,当然这些今天已经广泛应用了,当时我们的客户用上之后还是非常震撼的。
知识面的宽广对于一名出色的架构师来说是必不可少的技能,也许很多人对架构的理解还停留在设计模式,重构,SOA等等的软件层面,然而这仅仅是非常基本的东西,架构师的脑子里不光需要知道让软件如何高效的运行,还需要知道如何去结合网络,存储,甚至一些文件系统的特性,比如GFS,NFS,XFS,NTFS等等,而且架构师还需要知道一些编程语言的特性,C,C++,Java,PHP,Python,Lisp,JS等等,现在是一个混合编程的时代,只了解一种语言,即使再精通也会使你在架构系统的时候受到很大的局限性。
再有一点,架构师需要对数据库技术有深刻的认识,因为现今是一个信息时代,大量的信息都是需要存储并检索的,数据库设计的不好,将会严重影响系统的性能,而这一点往往会被我们的设计人员忽略,他们只知道遵守那些范式而不会结合数据的特性去设计数据库。
看你的编程情况,你好像做PHP开发比较多,PHP比较适合B/S结构的应用开发,这会限制一个架构师的思路,我建议你再学习一门适合做C/S开发的语言,拓宽自己的视野。
从一个程序员到架构师是一个很大的变化,架构师需要从大的方面考虑,而不只是考虑这个模块该用哪种设计模式去开发。不能急于求成,也许是我自己变化的比较慢,我用了10年的时间,这10年里,我使用超过一年的编程语言包括了delphi,C++,Java,python,使用的数据库包括了oracle,infomix,sybase,sqlserver,mysql,javadb,sqlite等等,使用过大型机,小型机,服务器。unix,linux,windows都至少做过两年以上的开发,这些使用和开发的经历会大大增强一个人在做架构师这个职业时的技术素养。
总之,想要成为架构师,需要有耐心,不断学习,拓宽自己的视野,不仅仅局限于自己眼前的项目,关注开源技术,关注热门技术社区的新动向。