当前位置: 首页 > 科技观察

技术总监一直从事微服务程序员的工作,辞职了

时间:2023-03-15 22:44:36 科技观察

微服务的概念不是一天两天的,要追根溯源还是要靠SOA。毕竟微服务只是一种比较现代的、细粒度的SOA实现方法,并不是突然从天而降的。但不得不承认的是,IT架构已经从allinone转变为微服务架构,微服务架构师模式开始被越来越多的企业所接受。按照ThoughtWorks资深科学家Mr.MartinFowler的定义:“微服务架构是一种架构模式,提倡将单个应用程序拆分成一组小的服务,服务之间相互协调配合,共同服务用户。提供最终价值。每个服务都运行在自己的进程中,服务之间使用轻量级的通信机制(通常是基于HTTP协议的RESTfulAPI)进行通信。每个服务都围绕特定的业务构建,并且可以独立部署到生产环境、类生产环境等,另外,尽量避免统一集中的服务管理机制,针对具体的服务,根据业务选择合适的语言和工具上下文。构建它。”如何避免盲人思维?比如某大型互联网公司技术总监深感微服务架构具有复杂可控、灵活扩展、独立部署、开发性强等诸多优势。当然,最重要的是TCO有所降低,毕竟在微服务架构模式下,当一个组件发生故障时,不会有单体架构系统进程内扩散等弊端,故障会被隔离在一个单服务,看似好处多多,但是本部门的程序员却表示不满,因为在他们看来,自己做了很多无用的工作,而且无论是分区数据库架构,还是微服务架构的测试有很大的挑战。Nginx认为“微服务”强调服务的规模。实际上,一些开发人员提倡建立10-100LOC的稍大服务组。虽然小服务更容易被采用,但不要忘记这只是终端的选择,并不是最终目的。微服务的目的是有效拆分应用,实现敏捷开发和部署。OhnAllspawvs.AdrianCockcroft微服务之争由此可见,当谈到微服务这个热门话题时,没有绝对的好坏之分。笔者认为,企业在选择IT架构模型时应根据自身需求进行权衡。如果他们只需要构建一个简单的应用程序,那么就没有必要使用微服务架构。单体架构可能更适合你;如果企业需要构建一个复杂的Application,微服务架构分解成部件的功能是值得肯定的,但是微服务在应用过程中也有自身的不足,需要我们警惕。