希望你看完这一篇，能充分认知和了解架构师，认知对了，事就好办了。
01
架构师的准确定义
架构师的职责应该是立足于技术和业务之间的中间角色或者平衡点，在针对业务深刻理解的基础上，针对业务中存在诸多变数，挑选适合的技术架构和技术方案。
结合现有的技术团队的水平与特点，选择合适的技术架构进行落地和实现。
02
首要任务，技术的选型
当你做架构设计时，必然会面临技术选型的抉择，不同的技术方案，架构也可能完全不同。
比如架构后端语言选型，采用java语言开发，还是php语言，c#开发，ruby开发，还是python开发，还是groovy开发等。
为什么要选择这门语言？这是重点，是业务需(能快速开发发布php)，还是人员需要(java开发资源多)，还是未来可拓展架构需要(.net大型网站全面转型java，你还会继续使用.net么)，还是技术需要(python在网络爬虫以及未来人工智能的使用场景)...
再比如移动端选型，App是纯原生开发，还是WebApp，抑或HybridApp？iOS开发，语言上是选择Objective-C还是Swift？架构模式用MVC，还是MVP，或者MVVM？
很多技术架构的选择没有弄清楚，盲选选择技术架构，不仅不有利于开发，更不有利于业务需要。
这里普遍犯错的地方就在于大部分都是半桶水，以为按照网上的经验就可以直接copy，直接搬砖过来，实则根本没有这块的经验。
再举一个例子，早期访问量巨大的.net转java，京东、携程..等等，为什么要转是一回事，怎么转是另外一回事，再比如最近某一国内最大的游戏网站.net开发，现在要转java，找了一批人，最后发现java领域精通的人，往往并不知道.net领域的问题，这就涉及到怎么转，哪部分可以转java，哪部分不能转，而不是全转，为什么？
所以，架构师在做每一个决定需要考虑诸多因素，再比如高效的技术选型需要很高的学习曲线，在工期与人员素质之间需要权衡。精妙的技术架构并不能解决业务的快速迭代和变化，技术架构都是后知后觉的，无法准确的预知业务层面的变更与方向，故只能是跟随的角色，这样就必然会面临技术架构迭代和升级的需求，技术架构从来都不是建立了之后，就无需修改，可以承载各方的多重期望。
03
其次，业务理解和拆解能力。
这一项是架构师的胜负手，大部分做IT的朋友，对业务的理解和拆解能力是比较差的，总以为把技术选型，架构搭建，技术难点发展为最核心的架构师能力。
今天，借用优知学院再次重申，这样的观点是及其错误的。没有商业，没有访问量，没有增长，没有业务需要，需要技术来干什么？关于这一点，很多同学不以为然，之所以技术这10年发展迅速，需要感谢互联网的快速发展，否则我们都失业了。特别是这一波人工智能的发展，未来基础性的开发人员肯定会锐减，为啥？根本不需要这么多开发人员，基础性开发工作，可替代性太强了。
架构师需要深入理解业务，不管是业务的流程，还是整块业务需求，甚至包括业务细节，你需要重点
