白癜风秘方 https://m.39.net/pf/a_4575144.html前言随着各行各业的快速发展，业务规模的不断扩大，不可避免地造成原有架构不能够适应快速的增长和变化。这时，微服务就进入大家的视野，其实在微服务之前，很多公司已经做过服务化的改造，并且取得了一定的成果，但是对于整体流程的标准化还有一定有差距。那么，什么是微服务呢？微服务
概述准确地说，微服务是一种软件架构模式，将大型系统或者复杂的应用分割成多个服务的架构，服务之间互相协调、互相配合，为用户提供最终价值。每个服务都有独立的生命周期，可以单独维护和部署，各个业务模块之间是松耦合的，比传统的应用程序更有效地利用了计算资源，应用的扩展更加灵活，能够通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。一个微服务的架构如下图所示，单体应用被拆分成多个微小的服务。也有人将微服务的开发比喻成搭积木，每个服务都是一个零件，使用这些不同的服务可以搭建出不同的形状。简单地说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。其实这里蕴含着自古以来的真理，就是分而治之，当一件事情大到不能处理的时候，就使用一定的切分方法，将其变成很多微小的类，然后分门别类地进行处理，以达到最好的效果，最终实现1+12的功效。微服务优点开发简单：每个服务完成独立的功能；技术栈灵活：可以选择不同的语言完成不同的服务，发挥各种语言的最大优势；服务独立无依赖：每个服务都可以单独部署，一个服务出现问题不会导致整个系统瘫瘓；独立按需扩展：以应对高并发与大流量；可用性高：当其中一个点出现问题时，能够及时切换，不影响业务的正常运行；复杂应用解耦为小而众的服务：拆分可以基于一定的原则，将耗时的应用解耦；各服务精而专：也就是我们常说的专人干专事，映射到微服务中就是专服务干专事；服务间通信通过API完成：选择轻量的API通信。微服务的优点和缺点（或者说挑战）一样明显。微服务缺点多服务运维难度：服务的增加意味着运维的困难，如何有效地管理是一个挑战；系统部署依赖：当业务复杂时，系统之间的耦合关系高度耦合，如何高效部署是一个挑战；服务间通信成本：包括网络延迟、接口不可用性等，保证服务的高可用性是一个挑战；数据一致性：各个服务间如何有效地共享数据，确保相应服务的数据需求一致性是一个个挑战；系统集成测试：拆分后，原本需要测试的内容成倍地增加，如何高效地降低测试成本是一个挑战；重复工作：服务拆分之后，由于信息的不对称导致的重复性工作，如何有效抽象是一个挑战;性能监控：原本只需要一个监控的部分，现在需要分开监控，如何快速定位问题是一个挑战：沟通成本的成倍增加：服务拆分后，各个服务由单独的人来维护，如何高效地沟通是一个挑战。为什么微服务从一般的平台遇到的问题说起：服务配置复杂。基础服务多，服务的资源配置复杂。传统方式管理服务复杂。服务之间调用复杂。检索服务、用户中心服务等，服务之间的调用复杂，依赖多。服务监控难度大。服务比较多，机器部署复杂，服务存活监控、业务是否正常监控尤为重要。服务化测试问题。服务依赖性比较大，测试-一个小的功能，周边服务也需要启动。单体架构和分布式微服务架构的区别从上面的表格我们可以看到，分布式系统虽然有一些优势，但也存在一些问题:架构设计变得复杂(尤其是其中的分布式事务)；部署单个服务会比较快，但一次部署多个服务会变得复杂；系统的吞吐量会变大，但是响应时间会变长；运维复杂度会因为服务变多而变得很复杂；架构复杂导致学习曲线变大；测试和查错的复杂度增大；技术很多样，带来维护和运维的复杂度提升；管理分布式系统中的服务和调度变得困难且复杂。也就是说，分布式系统架构的难点在于系统的设计、管理和运维。随着服务的拆分，新的问题随之而来。客户端如何访问这些服务?这些服务的调用情况?切分是否合理?是否安全?如果受到攻击应该如何应对?是否可以使用限流或者降级的方式来及时解决?应对这些问题，API网关是一个不错的解决方案。当有新的设备需要调用这些接口时，可以复用原有接口，不需要进行二次开发。接口的维护也会更有条理性，对于访问次数、安全等问题，都可以在这一层进行解决，如下图所示。解决了应用前端访问的问题后，服务之间的相互调用也是一个问题，如果整个系统内部调用关系混乱，就会带来非常多的不必要的问题。所以约定好服务之间的通信方式是非常有必要的。不管是开源还是公司内部研发，都有非常多的解决方案。最简单的方式是通过RPC的调用，传输JSON或者XML，双方定义好协议格式，通过报文的方式进行数据传输。当多种服务需要互相调用时，服务的数量会急剧地增加，服务的治理就成为新的问题，另外还有不同服务的版本问题。如果不能通过一个单独的注册地址，像书的目录一样来管理整个服务结构，服务的调用就显示非常混乱。一般的分布式服务都有一个注册中心，例如，Dubbo是基于ZooKeeper进行的二次开发，自身提供管理控制台，可以对服务进行注册和查找，SpringCloud有Eureka,还有etcd、Consul等可供选择。经过上面的处理，整体.上来看应用已经达到了一个非常好的状态，但是每个应用服务仍然存在着单点问题，当一个服务出现问题时，有可能导致连锁的反应，使整个系统瘫痪。这时需要除监控告警外的一种容错机制来保障整体服务的可运行性。通过网关层的反向代理来实现高可用是一个不错的解决方案，访问层无须了解整个体系有多少应用提供，只需要关心服务是否能够提供服务，并且对必要的接口进行监测即可。当发现接口无法正常提供服务时，提供相应的告警机制，以
转载请注明：http://www.aierlanlan.com/rzfs/6651.html
