网站 网页,海南网站开发公司,月夜影视在线观看免费完整版,微信官网首页手机版戳蓝字“CSDN云计算”关注我们哦#xff01;作者 | 奎哥来源 | 不止思考微服务这几年不可谓不火#xff0c;很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展#xff0c;另一方面也可以看到一些盲目追技术热点的行为所带来… 戳蓝字“CSDN云计算”关注我们哦作者 | 奎哥来源 | 不止思考微服务这几年不可谓不火很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展另一方面也可以看到一些盲目追技术热点的行为所带来的危害比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施最后导致了项目的失败。微服务要想做好是一个非常复杂的架构今天就先只聊一聊微服务的一些基础架构算是入门篇。一、什么是「 微服务 」「 微服务 」由 Martin Fowler 提出它是指一种软件架构风格。一个大型的系统可以由多个微服务组成每个微服务是被独立部署独立完成自己的任务单元微服务之间是通过API方式进行通信调用是松耦合的。这个模式听着是不是很熟悉的感觉因为在提出「 微服务 」概念之前很多互联网公司的中大型项目早就是按照将业务拆分成独立单元的形式在部署和架构的这与微服务的思路是一脉相通的只不过实现方式没有现在这么规范与体系。那「 微服务 」到底是怎么演变过来的呢在做一个新项目的时候一开始项目大多数都很小都是「 单体应用 」这是很常见的做法。在项目规模小的时候这种方式开发效率和运维效率都最高符合互联网公司快速响应的要求。但是随着业务量越来越大项目也越来越复杂开发团队人员也越来越多。这个时候还采用单体应用问题就会很明显了。下面挑选两个最为常见的问题来举例协同问题多个人同时开发一份代码在工作协同上就会经常遇到代码冲突问题。可用性问题因为是单体应用即使改个最小的功能也需要整体发布不仅直接影响了线上可用性还可能会对正常功能带来风险。为了解决这些问题大家就开始考虑将「 单体应用 」进行拆分进行服务化部署。然后又随着 Martin Fowler对「 微服务 」概念的提出加上 DevOps 的流行进一步促进了微服务的火热发展。「 微服务 」的理念提倡每个服务都是单一职责且每一个服务都能实现自治因此可以带来一些明显好处部署简单每个微服务都可以独立去部署方便快捷。逻辑清晰将一个独立功能逻辑封装在单一微服务里面实现整体项目的逻辑清晰。可扩展因为可以随时增加和减少微服务可以很方便的扩展功能。可靠性高某一个功能的异常可以隔离在单一微服务里面可以提高整体可靠性。二、「 微服务 」的架构是什么样我们先来看一下「 微服务 」的架构图图片来源网络粉丝太少就懒得画图了大家发挥一下想象力将就的看看哈哈看起来挺复杂对不对事实上也确实很复杂。所以微服务并不是适用于所有项目、所有团队的。在应用之前一定要搞清楚是否适合自己。要保证这么一套微服务架构能成功运行起来我们起码需要以下这些 微服务的基础组件服务注册部署了一个微服务节点得让调用者知道啊当微服务节点有增加或减少的时候也得让调用者及时知晓啊。这些问题都是通过“服务注册”组件来实现的服务提供者将自己的服务地址等信息登记到“服务注册”组件中调用者需要的时候每次都先去查询“服务注册”即可。免去人工维护微服务节点的信息同步问题。服务网关是指提供给外部系统调用的是统一网关。主要做安全和权限控制等。配置中心微服务的配置中心是用来统一管理所有微服务节点的配置信息的。因为同一个程序可能要适用于多个环境所以在微服务实践中要尽量做到程序与配置分离将配置进行集中管理。包括微服务节点信息、程序运行时配置、变量配置、数据源配置、日志配置、版本配置等。服务框架是指用来规范各个微服务节点之间通信标准的。服务间通信采用什么协议、数据是如何传输的、数据格式是什么样的。有了这个统一的“服务框架”就能保证各个微服务节点之间高效率的协同。服务监控微服务运行起来之后为了能够监控节点的健康情况保障节点的高可行需要对各个服务节点进行收集数据指标、然后对数据进行实时处理和分析形成监控报表和预警。服务追踪一旦使用了微服务架构那么当有请求过来时就会经过多个微服务节点的处理形成了一个调用链。为了进行问题追踪和故障的定位需要对请求的完整调用链进行记录。这里的服务追踪与上面的服务监控是不同维度的一个是全局的一个是微观的发挥的作用也不一样。服务治理就是指需要通过准备一些策略和方案来保障整个微服务架构在生产环境遇到极端情况下也能正常提供服务的措施。比如 熔断、限流、隔离等等。当然上述只是一个微服务架构最为核心的基础组件一旦微服务体系过大例如有几十上百个微服务节点那么开发、维护、测试的成本就会非常大。因此一般还会引入 自动化部署 和 自动化测试 来提高协同效率。三、「 微服务 」入门如何避免踩坑你以为微服务架构都是下面这样的吗事实上更能是下面这样的哈哈。图片来源网络大家都在宣扬「 微服务 」多么多么的好例如易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实但是「 微服务 」带来的问题也很多尤其是对于刚入门的团队而言应用微服务后趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针不是所有项目都适用微服务有些项目规模还比较小或者项目才刚立项启动也只有三四个人负责开发维护这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务不仅是“杀鸡用牛刀”而且还无谓的增加了项目的复杂度本身一个单体结构就可以搞定的事情非得拆分N多节点人员又不足以支撑这么多节点的开发维护这完全是自找苦吃。反而是等项目成熟了、规模大了之后再开始慢慢将原有结构拆为微服务才是正确的做法。不要拆分过多过细的服务即使项目经过评估后适合拆为微服务架构但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒最后把项目搞的特别复杂整个团队都陷进去了。拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「 康威定律 」。什么样的团队就产生什么样的架构微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候得先评估一下团队人员和素质一般在开发期2-3个人开发一个服务是合理的在维护期1个人维护2-3个服务也是合理的。如果拆分过细开发人员跟不上会严重降低大家的工作效率。并且过细的服务会导致一个请求的调用链条很长不仅会影响请求的响应时间也会对线上问题排查带来增加难度。没有DevOps就不要急于微服务一个稳定的微服务架构是需要 持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps这些基础的建设都没有做好一上来就搞微服务的话就会导致实施过程中问题百出微服务的优势不能发挥。以上就是对架构设计中「 微服务基础 」的一些思考。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读屡试不爽的互联网架构三大马车抖音微博等短视频千万级高可用、高并发架构如何设计20大5G关键技术Fast.ai从零开始学深度学习 | 资源帖10个简单小窍门带你提高Python数据分析速度附代码程序员爬取 3 万条评论《长安十二时辰》槽点大揭秘暗网竟成比特币最大用户? 上半年5.15亿美元被用于非法活动真香朕在看了
