中山网站搜索排名,最好的做网站公司,关键词优化排名公司,sns网站需求在4月20日的阿里云栖开发者沙龙PHP技术专场上#xff0c;云智慧Technical VP高驰涛为大家介绍了微服务的前世今生#xff0c;分享了微服务架构实践中所面对的诸多挑战以及相应的应对策略。 本次直播视频精彩回顾#xff0c;戳这里#xff01; 直播回顾#xff1a;https://… 在4月20日的阿里云栖开发者沙龙PHP技术专场上云智慧Technical VP高驰涛为大家介绍了微服务的前世今生分享了微服务架构实践中所面对的诸多挑战以及相应的应对策略。 本次直播视频精彩回顾戳这里 直播回顾https://yq.aliyun.com/live/965 PPT分享https://yq.aliyun.com/download/3527
以下内容根据演讲视频以及PPT整理而成。
专家简介
高驰涛 (Neeke Gao)云智慧Technical VPPHP/PECL开发组成员具有10余年研发管理经验同时也是PECL/SeasLog、PECL/JsonNet、GoCrab等多项开源软件的作者。2014年加入云智慧致力于APM与大数据产品的架构研发崇尚敏捷、高效。
从一个问题谈起
首先从几年之前某CTO的一个问题谈起这个问题是“我们的系统将会拥有五千个微服务组件。我们应该怎么做”大家可以仔细思考这个问题我们都知道一个接口肯定无法称之为微服务达到十几个接口或许才能够叫做微服务。那么对于包含五千个微服务的系统而言又该怎么实现和管理呢其实这样的系统背后会存在很大的问题。 本次分享将会主要围绕以下三个方面内容展开
微服务的前世今生微服务的挑战应该怎么面对
微服务的前世今生
下图所展现的内容其实可以说是供大家在茶余饭后聊天的谈资如果想要知道微服务是如何诞生的那么就必须要了解以下四个领域的知识。 TOGAF全称为“开放组体系结构框架”TOGAF在上世纪七、八十年代的时候就已经由专门组织负责开发了但一直到1995年的时候美国国防部参与之后TOGAF才最终成型。举例而言大家手机里正在使用的产品和应用中很多都会用到SAP、IBM或者惠普等的软件而这些软件公司所遵循的就是TOGAF。可以说目前全球超过50%的企业正在使用TOGAF实践软件架构设计和开发。TOGAF是一个架构体系而并没有提供具体的架构方法。TOGAF包含了业务架构、应用架构、数据架构、技术架构等其实阿里云的全局组件也属于TOGAF中的技术架构领域其能够帮助客户减少各种繁杂的思考使得客户只需要关注于业务架构即可。 TOGAF有三个最为主要支柱 1)企业架构域主要是企业信息与业务流等 2ADM一系列的架构方法论 3企业连续性指的是在企业业务高速增长并且也不断变更的过程中保证架构体系的连续性。
DDD全称为“领域驱动设计”其包含了诸多的概念但是大家只需要记住主要的三句话即可。 1DDD是精简的业务DDD首先关注的就是业务把各种繁琐的业务流程精简成更细的链条 2DDD需要回答业务是干什么的能够满足什么需求达成什么目的 3不断迭代DDD的不断迭代与TOGAF的企业连续性类似。
SOA全称为“面向服务架构”其理论也非常多但是大家也只需要记住三点。 1SOA解决了信息孤岛的问题不让信息变成孤岛 2业务重用从业务角度将各个服务组合成一个个中间件或者服务将其提供给用户或者其他系统 3SOA使得系统成为互联互通的信息群。
GRASP原则全称为“通用职责分配原则”其实很多大家耳熟能详的概念如“低耦合”、“高内聚”都来自于GRASP原则。其与设计模式不同设计模式指导如何实现系统而GRASP指导如何划分。GRASP原则指导定义业务架构以及API等相关内容和划分服务其理论内容也非常多但是只需要记住三个关键 1自己干自己的事 2自己只干自己能干的事 3自己只干自己的事强调了资源划分。
在软件工程的教科书上给出了微服务架构的定义微服务架构是一种架构模式它提介将单一应用程序划分成一组小的服务服务之间互相协调、互相配合为⽤户提供最终价值。每个服务运行在其独立的进程中服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTFul API)。每个服务都围绕着具体业务进⾏构建并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外应当尽量避免统一的、集中式的服务管理机制对具体的一个服务⽽言应根据业务上下⽂选择合适的语言、工具对其进行构建。而这些教科书上的内容或许在当下来看已经过时了。
微服务带来的优势 那么我们使用微服务架构的时候到底得到了什么东西呢其实得到了很多这里为大家总结了四点最为明显的优点。 1使得开发和迭代变得更加敏捷使用微服务架构使得敏捷开发成为可能 2易于扩展和收缩一些公司基于Kubernetes、Docker等技术可以在几秒内拉起上万个微服务当大型流量冲击到达的时候可以实现无损地承担全部流量同时实现用户无感知而当数据访问量降低之后又可以实现快速缩容 3多技术栈可能目前智慧云的技术栈非常全面虽然开发人员只有60多人但是开发语言却多达10多门而使用微服务可以有效地组织各类开发人员 4高可修改性比如实现数据库的快速迁移通道的快速切换等。
微服务带来的两点疑问 这里再提出两个问题虽然微服务能够带来诸多优点但是也存在两点疑问。第一个就是“微服务架构你的系统变得更健壮了吗”第二个则是“使用微服务让系统变得更快了吗”对于这两点而言可能说是见仁见智的。有人说因为组件变得越来越多可监控性就会变难因此系统健壮性就会变得越来越差也有人说因为将系统拆分得越来越细因此健壮性就会越来越强。如果单体架构是串行的那么使用微服务可以将其变成并行的和分布式的而多个组件之间进行通信也会使得通信成为性能瓶颈那么使用微服务到底是变快了还是变慢了呢这两个问题都很难以回答。而作为一个架构师或者开发者需要进行深入的思考。
微服务架构面临的挑战和思考
这里为大家总结了在使用微服务架构的时候所需要面临的8条挑战和相关的思考。
1. 小即是多 当业务从大变小的时候也意味着业务变多了。由大变小可以使系统变得更加容易维护和修改但是由少变多又会使得问题更加复杂因此也会有很多的挑战。第一个问题就是多节点、多服务和多状态。系统中的节点、组件服务变得更多了那么节点和服务之间的状态也会变得更难维护更加复杂。基于前面提到的四种知识其实可以将从大变小和从少变多这两个转变进行折中使得其变得更加可控。而解决这个问题的关键在于对于服务的合理拆分主要有三点可以考虑即数据资源、业务功能以及服务对象。
2. 债务管理 比如Bug、代码缺陷、未完成的功能或者版本不兼容等问题都是债务。当服务变得越来越多的时候债务往往就会变得更多。为了解决这些问题其实有这样的几种策略比如单元测试如果单元测试做的足够好那么代码缺陷的可能性就会变得更低一些可以将服务由少变多所造成的债务变多情况进行收敛集成回归这部分提供了很多工具去做这件事情不用开发者自己去做版本管理这里指的是静态库的版本管理动态库指的是正在变更中的库而静态库指的是不再变更的库和配置项这一点控制不好就容易使得系统管理混乱迭代冲刺这是一种组织方式当有很多技术债务需要进行管理时如何将这些债务一点点处理掉或者把发散的趋势收敛住迭代冲刺就是一种做法Bug Crash这是智慧云团队自己发明的一个名词相当于是对于Bug的大扫除无论采用传统的还是敏捷的开发模式都有一些Bug存在因此定期会组织全体开发和测试以及产品将自己的产品用一遍进行Bug大扫除回归总结无论采用什么开发模式在一个迭代周期完成之后回归总结是少不了的也需要通过一些方法解决新发生的问题或者将其封闭住不使债务继续蔓延。
3. 复杂的服务依赖 如果只有一个或者几个组件那么其实不存在服务依赖问题而如果有几千个组件那么服务依赖将会成为巨大的问题。举例而言如果用户服务需要调用订单服务那么在启动的时候需要进行一些初始化任务那么一个服务的版本发布可能导致系统全面瘫痪这就是复杂服务依赖问题。为了解决这个问题首先就需要服务发现机制比如使用etcd或者Zookeeper等首先服务发现中心也需要是分布式高可靠的那么服务起来之后需要把自己的名字和调用方式告诉服务发现中心注册上去对于服务调用者而言只需要从服务发现中心那里通过约定好的名字获取服务调用地址即可。依赖唤醒是有一个相对比较新的东西比如大流量突然打进来的时候A服务需要从原来的10个启动到100个而B从原来的3个肯定也是不够用的因此需要通过唤醒的机制将服务拉起来而不是被动的被通知。还有一种情况也需要使用到依赖唤醒机制比如缓存穿透问题正常情况下缓存是生效的不会存在穿透的情况但是可能因为某种异常使得缓存不生效了会将大量的流量打到DB里面去使得服务变得不可用了整个服务雪崩掉针对这些问题一般会开发一些挡板服务可能会给出一些固定的数据而这些挡板服务也有可能会面临这种突发的流量也需要通过依赖唤醒的机制实现唤醒。此外还有灰度发布和AB测试这两点是相关联的。还有多版本共存问题对于服务的多版本也是一个技术债务问题需要考虑如何将其旧版本拿下来。
4. 消息通讯 如果系统中包含多个语言栈多种实现方式。那么统一标准是必须的要么统一一种RPC或者就使用RestFul API等。消息中心也是一种处理做法这一点在Java中应用很多消息中心并不是消息队列而是一个事件驱动的消息中心。此外还有通讯网关这在使用微服务的时候也是一个必要点其主要解决了监控问题而且可以通过网关起到中控的作用比如安全、性能以及用户校验等任务。
5. 分布式事务 在实现分布式事务的时候可以采用2PC或者3PC原则来实现2PC原则是通过全部节点投票和执行两个步骤完成的并且是阻塞的而3PC则不同虽然在一个具体的事务里面可以是阻塞的也可以是非阻塞的。3PC协议则是通过“Can-Pre-Do”三个步骤来实现的其实PDU就是3PC协议在单体中的实现方式。而在分布式系统中3PC有三种实现方式使用分布式的事件驱动、最大通知以及两阶段补偿TCC。
6. 花式故障 很多时候当系统出现问题可能需要花费数周和很多人力才能找到根源所在可能因为系统太多使得系统架构师也无法清楚系统与系统之间的关系。面对诸多的花式故障也有多种策略可以应对比如全链路追踪比如使用Open Tracking主动拨测很多用户端的APP里面内置探针使其可以接收Server端的指令来定期探测接口和服务是否正常。
7. 中心与去中心 中心与去中心可以算是一个永恒的话题上图中展示的配置、发号、日志、调度、状态以及预警其实对于比较成熟的大型系统而言这六点都是需要中心的。
8. 组织危机 最后一个问题也是最大的问题。其实要实现向微服务架构的变更的时候最大的问题就是组织危机。这一点与开发者关系不大但是对于Team Leader以及组织的管理人员而言关系就非常大了。架构的转变需要考虑到信任危机、过期维护、多语言栈、沟通协作、安全网关以及轮岗结对等问题。
总结
总结而言最重要的观点有两个微服务不是银弹。不要让重复的事情做两次。
原文链接 本文为云栖社区原创内容未经允许不得转载。
