框架
项目和人类一样，总是会死亡的，有时候会突然死亡，有时候回自然死亡；在自然死亡这一边，有的人去世的很早，有的人则寿命很长，长寿的人，通常都是生活更规律的；项目也一样，框架更好的项目活的更久，框架不好的项目，上线同时就死亡了。
框架是一种规律，他并不是保证项目成功的基础，他只是让项目存续更久，存续更健康的依赖，他可以让病人在重病时，依靠药物还能简单自理，而不用躺着病床上输液。
微服务框架
微服务本质上是用于拆分业务的，因为业务被拆分成了多个服务，所以，为了保证被拆分的服务的健康，使用请求分流，服务生降低，熔断等技术来维持服务的高可用；因为服务被拆分了，服务日志也跟着被拆分了，所以为了保证异常排查的效率，需要进行日志收集。
框架是架构师的工具，微服务框架也同理，它总归是要服务于项目的，所以。我们在搭建微服务框架的项目时，不用太纠结微服务的概念。比如，你的微服务项目没有做熔断，有人过来说它不是微服务，其实你是不用在意的；作为架构师，你要知道，你是服务于项目的，如果你衡量的人员，进度等一系列客观因素后，判断熔断和升降级可以不做，那就可以不做，保证进度才是第一要务，要相信自己写的框架，即便没有熔断和升降级也可以健康运转好一段时间。但是，如果你做的是微服务开源框架，这些功能就是必须的了，架构师可以不用，但框架不能没有。
架构师
很多人认为学会微服务了，就可以当架构师了；其实不然，当架构师并不一定要会微服务，同理会微服务也不见得可以当架构师。
其实，微服务的概念并不难，相信很多高级软件工程师只要百度几天，然后消化一个月，基本上都能理解的七七八八。那么，这些高级软件工程师就这样步入架构师了吗？理论上不是，在没有特别详尽的掌握细节之前，我认为都没有架构师的水平，但这并不代表他们做不了架构师的岗位。
程序员有个特点，他们对自己没完全掌握的东西，有着天生的不自信，所以他们在自己未学会架构之前，是不敢应聘架构师的。但有一种高级程序员是不一样的，他们本身就不是特别专研技术，并不致力于提升开发效率，他们相对更擅长沟通和写文档，我把他们称为【没有腿的程序员】。他们对技术没有天然的畏惧，所以他们学习了概念就敢应聘，理解的概念就有了自信。当然了，他们是无法落地的微服务或其他框架的，因为他们没有腿。不过他们善于向老板夸大项目难度，然后招聘很多很多的人员，并且善于用人，他们会把熔断，升降级，日志管理，网关、服务查询等功能分别让普通的程序员来开发，然后出现问题就把问题定义为团队管理问题，然后开始搞devop或其他概念来管理团队。当然，结果通常是需求和代码都乱的像一锅浆糊，这也是祖传代码出现的最基础的原因，因为项目的起手式就乱了，后面自然就是越画越黑。
我有一种与众不同的认知
在招聘网站上，我们经常会看到招聘高级程序员或架构师要求会微服务，但同一城市不同公司给出的工资可能差一倍。仔细阅读招聘需求，我们会发现，其实他们的要求都一样，那为什么工资差距这么大呢？
我是这样理解的，有些公司招聘的就是普通程序员，他们只是未来、可能会用到微服务；有些公司已经在做微服务了，而且大概率已经做的满头包了，所以他们需要招聘一个有经验的高手。
在应聘这样的岗位时，【没有腿的程序员】是领先我们一个身位的，这是为什么你技术已经不错了，却总是应聘架构师失败的原因，因为公司面试过很多人，有一堆【没有腿的程序员】都表现优异，所以公司无论怎么筛选，都不会选择你做架构师。
所以，想做架构师，先包装自己，腿是可以慢慢长出来的，【没有腿的程序员】在架构师的岗位上干一干，如果真把腿长出来了，那他们可就不止领先我们一个身位了；不过通常他们是很难二次发育的。
微服务必死
我们应该都听过做微服务必死，中台必死吧；这是因为微服务项目的失败率非常高。通常人们把它归结于饼大嘴小，累死的；但，其实他们死亡更多的原因是因为使用了不正确的领导；因为微服务虽然很消耗团队，会让小团队疲惫翻倍，但并不是无法做项目的，微服务项目失败率如此之高，跟微服务本身没有必然关系。其实，这样的领导，搞微服务是死，他搞前后端分离也一样能把项目搞死。
结语
框架是死的，人是活的，把项目失败的原因归结于开发模式的，都是学艺不精而已
本文作者：net架构师，全栈.Net软件工程师
声明：本文为 脚本之家专栏作者 投稿，未经允许请勿转载。
