平山做网站优化,二级目录网站怎么做,做一个网站需要怎么做,宜昌住房和城乡建设厅网站1 微服务历史
2005年#xff1a;Dr. Peter Rodgers提出Micro-Web-Services概念2011年#xff1a;一个软件架构工作组使用microservice来描述一中架构模式2012年#xff1b;这个工作组正式使用microservice来代表这个架构2012年#x…1 微服务历史
2005年Dr. Peter Rodgers提出Micro-Web-Services概念2011年一个软件架构工作组使用microservice来描述一中架构模式2012年这个工作组正式使用microservice来代表这个架构2012年ThoughtWorks的James Lewis针对微服务概念发布演讲2014年James Lewis和Martin Flower合写了一篇学术性文章详细阐述微服务 虽然微服务也提到了服务SOA中也有服务这个概念但是并不是说两个是同一个东西
2 微服务和SOA关系 微服务和SOA的关系和区别有几个典型的观点 微服务是SOA的实现方式SOA是一种架构理念而微服务是SOA的一种具体实现方式使用了Http RESTful来实现ESB微服务是去掉ESB后的SOA可以发现微服务中没有ESB这种具体的总线概念都是直接使用http请求来访问其他服务微服务是一种SOA相似但本质上不同的架构概念两个虽然类似但本质上只是都拥有了服务这个概念的两种架构 微服务与SOA实际对比后可能才能了解到这两个架构的关系 服务粒度SOA要更粗一些而微服务则要细一点服务通信SOA同意ESB作为通信组件负责服务定义服务路由消息转换消息传递总体是重量级的实现而微服务则是推荐同意协议和格式方便传输和转换服务交付SOA并没有交付要求更多是考虑兼容现有的系统微服务则是要求快速交付一般要采取自动化测试、持续集成、自动化部署等敏捷开发的最佳实践不然一旦服务不断增加就会导致交付成本增加可以想象100多个服务要进行重新上线会有多么恐怖应用场景SOA更适合庞大、复杂、异构的企业级系统因为重构和优化成本过高只能使用兼容模式进行处理微服务责适用于快速、轻量级的互联网系统因为变化快需要快速尝试并且新兴面对的不是老旧系统对比表格如下可以得出SOA和微服务本质上就是两种不同的架构只不过都有服务这个概念
对比维度SOA微服务服务粒度粗细服务通信重量级ESB轻量级例如HTTP RESTful服务交付慢快应用场景企业级(老旧系统)互联网 可以发现微服务是一种优秀的架构模式且比SOA要优秀那我们应该把架构重构为服务吗 答案是不一定请记住三原则中的合适原则微服务的需求你用的上嘛且在SOA适用的系统中转换为微服务只会徒增实施难度和成本
3 微服务的陷阱 微服务不是无所不能且全是优点能不能用微服务重点是合适原则如果不考虑团队规模业务发展基础技术支持直接上微服务那么只会在这个坑里越陷越深 坑
服务划分过细服务间关系复杂单个服务复杂度确实下降了但是你几百个几十个微服务也不见得系统的整体复杂度下降了只不过是把单服务内部复杂度转移到了系统整体上(笑容不会消失只是转换到了我的脸上)服务数量多团队效率下降团队规模要是小一点一个负责好几个服务是真恶心开发、单元测试、打包、部署、整体测试等多个环节都会恶心到你调用链长性能下降如果不拆分那么就是在机器内部进行逻辑运算和方法调用快的一批但是微服则会一个服务调另一个服务要是中间遇到网络分区等问题可能导致接口拥堵等问题调用链长问题定位难本身我们看日志或者异常的message就能找到问题但微服务存在故障扩散现象快速定位就变得异常难没有自动化支持无法快速交付如果没有系统化系统支持那么全是人工去测试去部署去交付去实施那么出问题是必然的(如果你没有那么你总会遇到的)而且速度还是硬伤。没有服务治理微服务数量多了后管理混乱本质上就对熔断限流降级服务注册和发现以及负载均衡远程调用的方案设计要更加的合理符合直觉
4 微服务最佳实践 微服务的坑可以提炼为拆的过细基础设施不健全微服务不轻量级 带着以上问题看看微服务的最佳实践该怎么做
4.1 服务粒度 粒度划分过细可能会导致出现问题但是过粗又会增加每个服务的负载导致系统的性受到影响所以要划分的合适这是解决问题的关键作者给出的建议是基于团队规模进行拆分 三个火枪手即一个微服务三个人负责开发并且会随着人数的增加而继续拆分微服务如目前团队有6个人那就拆成两个微服务如果增加到了12个人同时系统的功能和复杂度也会增加这时候就可以将2个微服再分别拆为两个相应降低了单个微服务的复杂度
?为啥是三个人负责一个呢为啥不是2个人不是4个人
简单-三人成虎从科学角度出发如果3个人负责一个系统系统的复杂度刚好达到每个人都能全面理解整个系统还能分工。还能形成高可用即使一个人请假了还有两个人加班不会觉得孤独且三个人能形成有效的讨论能快速达到一致意见如果是两个可能发生分歧一个人的话可能陷入思维盲区更多人的话可能出现有人摸鱼
4.2 拆分方法 定好了拆分大小后就需要确认拆分的方式了一般有如下几种基于业务逻辑拆分、基于可扩展拆分、基于可靠性拆分、基于性能拆分 基于业务逻辑拆分这是一种常见的拆分方式简单来说就是按照功能模块划分 首先要计算大概服务数量范围再确认合适的职责范围如果团队规模是10个人划分4个服务那么登录注册用户信息管理可以划分到用户服务的范围作为微服务如果是100人那么用户登录就可以是一个单独的微服务了 基于可扩展拆分将稳定的服务和经常迭代的服务拆分开稳定的可以粒度划分更粗毕竟不会再进行升级和迭代所以系统内部的复杂度高一点也没问题而需要快速迭代的服务则划分细一点方便开发对具体功能敏捷开发基于可靠性拆分本质上来说就是将核心业务和非核心业务拆分能够对核心的业务进行高可用的机器冗余方案非核心业务没必要也不需要进行高可用冗余反而会导致成本上升基于性能拆分和上面的可靠性拆分类似都是为了进行机器冗余时对关键的需要进行高性能运算的服务拆分出来进行机器扩展降低机器冗余的成本 上述的拆分方式并不是只能选择一个可以在系统划分时组合排列比如使用了性能划分后还可以进行可靠性划分 4.3 基础设施 微服务的关键确实是“微”、“轻量化”但是其“自动化”也是一个重要点如果因为自动化不到位即使服务划分的再好再细节每次部署、测试的时候以及上线等问题带来的资源、时间消耗就不止服务划分、轻量化开发时消耗的时间了 基础设施如下
服务发现服务路由服务容错服务监控服务跟踪服务安全自动化测试自动化部署配置中心接口框架API网关 可以发现基础设施的搭建即多又繁琐像是把SOA的ESB转移到了基础设施上但是每个基础设施又有其作用 自动化测试原本大一统的系统拆分为多个独立运行的“微服务”且服务之间的接口数量大大增加并且微服务还提倡快速交付开发周期短如果测试等工作不能自动化要么增加人工成本要么增加研发成本(配置好自动化测试) 自动化测试包含单元测试、单系统集成测试、系统间接口测试至少都要做到接口测试自动化 自动化部署微服务多手动部署会有风险和问题自动化能相对解决这个问题 包括版本管理、资源管理、部署操作、回退操作等 配置中心微服务的配置生产环境和开发环境以及测试环节都是不一样的且不同的微服务可能有相同的配置如果改了其中一个还要手动改其他的。所以配置中心就是统一配置多个微服务都可以使用同一个配置信息改了配置文件后所有微服务都会生效。 包括配置版本管理增删改查配置、节点管理、配置同步、配置推送等 接口框架我们需要统一整个微服务的通信协议以及序列化协议能够方便我们接收请求以及处理响应以及处理数据格式API网关微服务之间是互联互通的内部你怎么去请求怎么去交流有内部的方式如果外部系统或者请求就不知道该如何访问某个服务的接口且接口权限也不好统一 网关能很好解决这个问题作为微服务统一的入口可以进行鉴权、权限控制、传输加密、请求路由转发、流量监控请求日志等 服务发现(当前服务怎么找到依赖的服务的地址)微服务数量多如果各个服务之间的依赖使用手工录入的话工作量大并且配置中心很多时候可能也会依靠服务发现去做自动化配置且一个服务扩容后该怎么路由达到负载均衡等以及灰度发布 自理式指每个微服务完成自己的服务发现代理式服务消费者不直接与服务提供者通信而是通过一个代理通常是负载均衡器或代理服务器来间接访问服务 服务路由有了服务发现之后对于某次具体的调用需要从符合条件的节点中选择一个发起请求 服务路由和服务发现紧密相关自理式服务发现的服务路由是微服务内部实现的对于代理式服务路由是有LB(负载均衡)系统实现的常见算法有随机路由、轮询路由、最小压力路由、最小连接数路由等 服务容错拆分微服务后单个微服务的故障率变小了但是被其他服务影响导致故障的概率却变大了单个微服务故障影响返回减少但是导致上下游发生故障后影响面积却又扩大了所以控制故障扩散就是服务容错的能力 常见的服务容错请求重试、流控、服务隔离请求重试重新向同一个微服务节点重新发送请求流控也就是我们常说的限流通常应对某类微服务请求突增且由于系统容量限制无法快速应对突发容量通常微服务节点的流控由自己实现服务隔离当某个微服务故障时让其下线避免故障扩散隔离又分为主动隔离、被动隔离、手动隔离 主动隔离指微服务自己发现自己异常后主动注销自己-降级被动隔离指被系统发现异常频率等触发了设置的阈值被系统注销-熔断手动隔离指人工判断系统故障后手工操作注销 三者可以一起使用能够更好的保证服务故障不扩散 服务监控实时收集微服务信息包括但不限于机器、网络、进程、接口调用数等 服务监控作用有很多收集信息预警收集信息实时分析可以避免故障后再分析减少处理时间可以在实时分析的基础上进行预警提前发现问题萌芽扼杀 服务跟踪跟踪每次请求的在微服务中的完整路径监控是很难实现的且每个请求都这样的话数据量会非常大 监控和跟踪的关系就是宏观和微观关系监控统计了路径的结果跟踪则是每次路径现在的服务跟踪大部分都是基于Google的Dapper论文《Dapper,a Large-Scale Distributed Systems Tracing Infrastructure》技术关键点如下 标注点 标注点会在一个完整的调用链中有自己的id类似于seata的分布式事务id而且我们可以控制在哪里打上标注点 比如一个元数据落标我们可以在任务开始时标记一下在数据库记录当前任务的id整个任务过程都是用这个id去标记和入库当任务结束后我们就可以查看每次任务的流程以及各个标注点的信息 跟踪树和span标注点可以说是很多跟踪任务的通用解决方案但是在微服务的服务跟踪中不仅需要记录标注点还需要集合调用链以及分支结构比如A服务调用了C和BC又调用了DB又调用了E此时就出现了分支如下所以span就是每个节点而跟踪树就是由每个节点的span组成的树结构每个span中又可以有标注点 AB E C D 服务跟踪主要有两个目的采样跟踪、染色跟踪 采用跟踪根据一定概率对请求进行采样跟踪基于采样数据进行分析通常用于检查性能不足等对系统消耗小且压力小染色跟踪针对某个特殊请求进行跟踪比如某个特定用户id某个特定的业务对象id常常因为这些特定对象会导致系统出现问题同时还不是大面积的问题所以很难定位问题需要进行染色跟踪的用户id或业务对象id 服务安全简单来说就是每个微服务的资源也需要进行鉴权和保护比如拥有A权限的微服务可以去访问用户信息微服务的修改接口拥有B权限的微服务能够访问用户信息的的获取接口 服务安全分为三个部分接入安全、数据安全、传输安全 接入安全只有经过允许某个微服务才能访问另一个微服务否则会被拒绝数据安全各个接口需要对应权限和授权后才能访问传输安全指某些敏感数据需要在传输过程中防窃取、防篡改保证数据的真实有效 通常可以集成到配置中心系统进行实现单独配置某个微服的接入安全策略和数据安全策略信息
5 总结
微服务概念的历史要早得多也不是Martin Flower创造出来的Martin只是将微服务进行了系统的阐述。微服务是一种和SOA相似但本质上不同的架构理念。微服务的三个关键词small、lightweight、automated。微服务和SOA不存在孰优孰劣只是应用场景不同。微服务并不是没有代价而是会带来系统复杂度、运维复杂度、性能下降等问题。微服务拆分的粒度遵循“三个火枪手”原则。真正决定微服务成败的恰恰是那个被大部分人都忽略的自动化(automated),而不是“小”(small)和“轻量级”(lightweight)。微服务并不是很多人认为的那样又简单又轻量级要做好微服务基础设施是必不可少的。
