标签：依赖性 通讯协议 业务 耗资源 java lin 做了 ada rap
随着各行各业公司的快速发展，业务规模的不断扩大，不可避免的造成原有架构不能够适应快速的增长和变化。这时，微服务就进入大家的视野，其实在微服务之前，很多的公司已经做过服务化的改造，并且取得了一定的成果，但是对于整体流程的标准化还有一定有差距。那么，什么是微服务呢？
准确的说，微服务是一种软件架构模式，将大型系统或者复杂的应用分割成多个服务的架构，服务之间互相协调、互相配合，为用户提供最终价值。每个服务都有独立的生命周期，可以单独的维护和部署，各个业务模块之间是松耦合的，比传统的应用程序更有效地利用计算资源，应用的扩展更加灵活，能够通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。
一个微服务的架构如图所示，单体应用被拆分成多个微小的服务：
也有人将微服务的开发比喻成搭积木，每个服务都是一个零件，使用这些不同的服务可以搭建出不同的形状。简单的说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。
其实这里蕴含着自古以来的真理，就是分而治之，当一件事情大到不能处理的时候，就使用一定的切分方法，将其变成很多微小的类，然后分门别类的进行处理，以达到最好的效果，最终实现1+1>2的功效。
微服务的优点和缺点（或者说挑战）一样明显。
优点
开发简单，每个服务完成独立的功能
技术栈灵活，可以选择不同的语言完成不同的服务，发挥各种语言的最大优势
服务独立无依赖，每个服务都可以单独部署，一个服务出现问题不会导致整个系统瘫痪
独立按需扩展，以应对高并发以及大流量
可用性高，当其中一个点出现问题时，能够及时切换，不影响业务正常运行
复杂应用解耦为小而众的服务，拆分可以基于一定的原则，将耗时的应用解耦
各服务精而专，也就是我们常说的专人干专事，映射到微服务中就是专服务干专事
服务间通信通过API完成，选择轻量的API通信
缺点（挑战）
多服务运维难度，服务的增加意味着运维的困难，如何有效的管理是一个挑战
系统部署依赖，当业务复杂是，系统之间的耦合关系高度耦合，如何高效部署是一个挑战
服务间通信成本，包括网络延迟，接口不可用性等，保证服务的高可用性是一个挑战
数据一致性，再各个服务间如何有效的共享数据，确保相应服务的数据需求一致性是一个挑战
系统集成测试，拆分后，原本需要测试的内容成倍的增加，如何高效的降低测试成本是一个挑战
重复工作，服务拆分之后，由于信息的不对称导致的重复性工作，如何有效抽象是一个挑战
性能监控，原本只需要一个监控的部分，现在需要分开监控，如何快速定位问题是一个挑战
沟通成本的成倍增加，服务拆分后，各个服务由单独的人来维护，如何高效的沟通是一个挑战
从一般的平台遇到的问题说起，平台的问题包括：
那么微服务的架构有什么优势，大家为什么都怀着极高的热情来应对微服务呢。
首先看一下两者的区别，单体应用和分布式应用都有哪些优点和缺点呢，通过下面的表格来做一下分析和对比？
从上面的表格我们可以看到，分布式系统虽然有一些优势，但也存在一些问题。
也就是说，分布式系统架构的难点在于系统设计，以及管理和运维。
接下来我们就一起来看一下架构的演变过程。
下图是我们非常熟悉的单体应用，或者说是非常传统的应用架构。
从图中可以看到，应用通过浏览器进行访问，当访问到订单服务的时候，分单服务提供相应的功能，然后去访问应用的数据层，数据层负责对数据的解析，这是一个极其典型的单体应用结构，这种结构所带来的问题显而易见，数据库存在单点，所有服务都耦合在一个应用中，当其中一个服务出现问题的时候，整个工程都需要重新发布，从而导致整体业务不能提供响应。这种结构在小项目中是没有什么问题的，而且操作起来非常灵活，但当业务量爆增的时候，就无法灵活应对了。
为了应对单体应对无法满足业务增涨，需要对数据库进行进一步的切分，以提高扩展性，下图就是一个切分后的架构图。
业务之间通过进程间的服务进行相互调用，数据库之间没有耦合性，不会存在单点故障。前端只需要调用相应的服务，返回自身需要的数据，然后与用户进行交互。可以看到，这种方式比传统的单体应用已经前进了一步，但是数据库层面仍然存在着问题，根据数据量需要评估是否使用读写分离的设计，服务层面也增加了相应的复杂性。前端调用随着调用接口数量的增加也急需治理。
随着服务的拆分，新的问题应运而生。客户端如何访问这些服务？这些服务的调用情况，切分是否合理，安全问题，如果受到攻击应该如何应对，是否可以使用限流或者降级的方式来及时解决。
应对这些问题，API网关是一个不错的解决方案。当有新的设备需要调用这些接口时，可以复用原有接口，不需要进行二次开发。接口的维护也会更有条理性，对于访问次数，安全等问题，都可以在这一层进行解决。
解决了应用前端访问的问题后，服务之间的相互调用也是一个问题，如果整个系统内部调用关系混乱，就会带来非常多的不必要的问题。所以约定好服务之间的通信方式是非常有必要的。不管是开源还是公司内部研发，都有非常多的解决方案。最简单的方式，是通过rpc的调用，传输json或者XML，双方定义好协议格式，通过报文的方式进行数据传输。
当多种服务需要互相调用的时候，服务的数量会急剧的增加。服务的治理就成为新的问题。不同的服务的版本问题。如果不能通过一个单独的注册地址，像书的目录一样来管理整个服务结构，服务的调用就侍显示非常混乱。
一般的分布式服务，都有一个注册中心，例如dubbo是基于zookeeper进行的二次开发，自身提供管理控制台，可以对服务进行注册和查找，Spring Cloud有Eureka，还有etcd，consul等可供选择。
经过上面的处理，整体上来看应用已经达到了一个非常好的状态，但是每个应用服务仍然存在着单点问题，当一个服务出现问题的时候，有可能导致连锁的反应，使用整个系统瘫痪。这时候需要除了监控告警之外的一种容错机制保障整体服务的可运行性。
通过网关层的反向代理来实现高可用是一个不错的解决方案，访问层无需要了解整个体系有多少应用提供，只需要关心服务是否能够提供服务，并且对必要的接口进行监测，当发现接口无法正常提供服务时，提供相应的告警机制，以微信、短信或者邮件的方式通知相关人及时进行处理。
随着服务的切分，业务的扩展，数据量的激增也是一个非常大的问题，如果采用传统的方案来应对，各种关系型数据库都有瓶颈，把运算量比较大，比较耗资源的运算，跨库统计查询的需求。
再下一步随着数据量的不断增涨，需要业务和统计分离。
统计一般都是比较耗时的应用，比如计算用户的留存情况，需要分析一周甚至是更长周期内的用户数据，如果使用在线的方式分析显然不太现实，所以，对于大数据量的分析和数据挖掘，需要从业务中抽取数据进行离线分析，然后将分析的结果进行展现。
针对以上的分析，可以看到，微服务需要具备极强的可扩展性，这些扩展性包含以下几个方面：
• 性能可扩展：性能无法完全实现线性扩展，但要尽量使用具有并发性和异步性的组件。具备完成通知功能的工作队列要优于同步连接到数据库。
• 可用性可扩展：CAP理论表明，分布式系统无法同时提供一致性、可用性和分区容错性保证。许多大规模Web应用程序都为了可用性和分区容错性而牺牲了强一致性，而后者则有赖于最终一致性来保证。
• 维护可扩展：软件和服务器都需要维护。在使用平台的工具监控和更新应用程序时，要尽可能地自动化。
• 成本可扩展：总成本包括开发、维护和运营支出。在设计一个系统时，要在重用现有组件和完全新开发组件之间进行权衡。现有组件很少能完全满足需求，但修改现有组件的成本还是可能低于开发一个完全不同的方案。另外，使用符合行业标准的技术使组织更容易聘到专家，而发布独有的开源方案则可能帮助组织从社区中挖掘人才。
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
都是做服务化，那么微服务与SOA的异同有哪些呢？
相同点：
差异点：
SOA和微服务的一个主要不同点就是自动化程度上的不同。大部分的SOA实现只达到服务级别的抽象，而微服务走的更远，它达到了对实现和运行环境的抽象级别。
而在一个规范的微服务中，每个微服务应该被构建成胖jar（fat Jar）其中内置了所有的依赖，然后作为一个单独的java进程存在。
既然谈到了微服务架构，就说一下通用的微服务都包括哪些组件：
服务注册是一个记录当前可用的微服务实例的网络信息数据库，是服务发现机制的主要核心，服务注册表查询api、管理api，使用查询api获得可用服务的实例，使用管理api实现注册、注销。
服务调用方从服务注册中心找到自己需要调用的服务的地址。可以选择客户端服务发现，也可以选择服务端服务发现。
服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。可以选择服务端的负载均衡也可以选择客户端的负载均衡。
服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。根据公司流量规模的大小网关可以是一个，也可以是多个。
将本地化的配置信息（properties, XML, yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。配置部分可以单独使用高可用的分布式配置中心，确保一个配置服务出现问题是，其它服务也能够提供配置服务。
以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。通常需要加入版本控制的概念，以确保服务的不同版本在升级过程中都能够提供服务。
微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。根据业务的不同适当的需要牺牲一些数据的一致性要求，确保数据的最终一致性。
记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。同时统计各个服务的调用次数，确保比较热的服务能够分配更多的资源。
系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过Docker等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。
标签：依赖性 通讯协议 业务 耗资源 java lin 做了 ada rap
原文地址：https://www.cnblogs.com/skyme/p/13130226.html
