本文首先简单介绍互联网架构的演进，然后介绍服务化，最后介绍微服务和最新的服务网格（ServiceMesh）。互联网架构演进集成架构在计算机软件发展的早期，一般的桌面软件都采用这种架构，无论是界面、业务处理还是数据处理，都被打包在一起。这种结构其实算不上结构，但也可以说是一个很好的结构，因为它足够简单。MVC架构，但是随着浏览器的出现，产生了web应用。Web应用的特点是界面部分显示在浏览器中，服务处理在服务容器中。页面展示一般采用css+js+html技术处理，后端可以使用java、php等语言，造成前后端分离。对于web系统来说，一体化的架构很难满足前后端分离的开发需求，于是诞生了MVC架构。MVC可以算是真正的架构，因为它不仅解决了前后端分离的问题，还引入了一种新的开发模式，采用业务逻辑、数据、界面展示分离的方式来组织代码，使得整个应用的层次更加分明，不仅降低了各层之间的耦合度，还提高了各层的复用性。但是，随着应用规模的不断扩大，应用模块的不断增加，整个应用变得越来越臃肿，越来越难以维护。因此，多应用架构应运而生。多应用架构多应用架构很简单，就是把原来的应用按照业务特点拆分成多个应用。例如，一个大型的电子商务系统可能包括用户系统、商品系统、订单系统、评价系统等，我们可以将它们分离出来，形成一个个的应用。多应用架构的特点是应用相互独立，互不调用。多应用虽然解决了应用臃肿的问题，但是应用之间是相互独立的，一些通用的服务或者代码无法复用。对于一个大型的互联网系统，分布式架构一般包括多个应用，应用之间往往有共同的服务，应用之间存在调用关系。此外，对于大型互联网系统还有一些其他的挑战，比如如何应对用户的快速增长，如何管理研发团队快速迭代产品开发，如何让产品升级更稳定等等。.所以，为了让业务复用和模块更容易扩展和维护，我们希望将业务和应用分开。某个业务不再属于一个应用，而是作为一个独立的服务来维护。应用本身不再是一堆臃肿的模块，而是模块化服务组件的组合。服务化的特点上面描述的分布式架构是面向服务的。我们再总结一下。服务化主要有以下特点：应用按业务划分为服务。每个服务都可以独立部署。该服务可以由多个应用程序共享。服务可以相互通信。服务化的好处那么采用服务化对企业有什么好处呢？？在架构方面，系统更加清晰。核心模块稳定，以服务组件为单位升级，避免频繁发布带来的风险。开发管理方便各个团队维护，任务明确，职责明确。业务复用和代码复用非常容易扩展服务实现方式如果要实现服务，最常见的方式就是使用RPC框架。由于服务组件一般分布在不同的服务器上，所以要实现服务化首先需要解决的问题就是RPC**远程服务调用**。类似RPC的解决方案还有很多，比如：JavaRMIWebServiceHessianHttpThrift...服务化面临的挑战上面提到，要实现服务化，首先需要解决远程服务调用的问题。此外，还有许多其他问题需要解决。服务越来越多，配置管理，复杂的服务依赖，负载均衡服务，服务扩容，服务监控，服务降级，服务鉴权，服务线上线下服务文档……上面说了服务治理，但其实如果你想要Servitization，服务治理是关键。那么有没有好的服务治理方案呢？答案是肯定的，而且很多人都在用这个框架，他就是-dubbo。dubbo是一个具有服务治理功能的RPC框架。dubbo提供了一套比较完善的服务治理解决方案，所以如果企业想要实现服务，dubbo是一个不错的选择。这里简单介绍一下dubbo服务治理相关的解决方案。服务发现注册服务治理领域最重要的问题是服务发现和注册。Dubbo引入了注册中心的概念，服务的注册和发现主要依赖这个服务中心。dubbo注册中心服务注册发现的具体流程：服务提供者启动，向注册中心注册提供服务的消费者启动，向注册中心订阅自己需要的服务。注册中心返回服务提供者列表给消费者。在provider列表中，根据软负载均衡算法，选择一个发起请求服务监控集群容错负载均衡RandomLoadbalanceRoundRobinLeastActiveConsistentHashdubbo服务治理优势注册中心只负责注册查找，不负责请求转发，压力小注册中心宕机影响消费或者，消费者本地缓存服务地址列表注册中心点对点集群，当一个宕机时，会自动切换到另一个服务提供者。服务提供者是无状态的，可以动态部署。注册中心负责无压力推送统计。本地内存累计次数，每分钟发送注册中心消费者调用服务提供者，自动软负载均衡可通过服务中心追溯依赖关系，监控中心提供扩容降级依据可开启Acl机制进行鉴权和降级spring集成，简单松耦合多种序列化协议对dubbo支持不足消费者仍需依赖配置中心消费者仍需依赖jar包配置provider缺少provider文档管理功能无统一入口不支持OAuth2.0内部认证不便管理没有外部应用认证接口，基本裸运行，不能直接对外暴露服务，不方便IT治理。微服务现在很多人都在谈论微服务，那么微服务到底是什么？这是我对微服务的理解。微服务有两个核心：微：服务的粒度要细，就是服务要细化到API服务：提供好的服务，让用户觉得好用（做到这一点并不容易）微服务（微服务）是一种架构风格，其中大型复杂软件应用程序由一个或多个微服务组成。系统中的每个微服务都可以独立部署，每个微服务都是松耦合的。每个微服务只专注于完成一项任务并将其做好。在所有情况下，每个任务都代表一个小型业务能力。微服务架构≈模块化开发+分布式计算从上图我们可以看出微服务很简单（好的架构应该是简单的），我们把服务拆分成API，就是一个完整的功能。那么我们把API丢到一个“云”上，用户就可以到“云”上去获取所有的API服务。这个“云”保证提供良好的服务。我们可以看到，有了微服务，服务对于用户来说变得特别简单，上面dubbo的缺点都在微服务中得到了解决。用户不再需要依赖任何jar包，不再需要去注册中心找服务，不再需要做鉴权处理，不用担心服务卡顿，不用担心不能使用服务，一切问题都由这“云”解决。这也是微服务的核心之一，提供好的服务。说到这里，大家应该对如何做微服务有了大概的了解，图中的“云”才是关键。接下来，我们就慢慢拨开这片云。实现微服务的关键是服务网关，所以上面说的“云”就是服务网关。要做微服务，我们先定义微服务需要具备的特性。常见的微服务组件和概念：服务注册：服务提供者将自己的调用地址注册到服务注册中心，方便服务调用者找到自己。服务发现：服务调用者从服务注册中心找到需要调用的服务地址。负载均衡：服务提供者一般以多实例的形式提供服务，负载均衡功能使服务调用者能够连接到合适的服务节点。而且，节点选择的工作对服务调用者是透明的。服务网关：服务网关是服务调用的唯一入口。该组件可以实现用户认证、动态路由、灰度发布、A/B测试、负载限流等功能。配置中心：将本地化的配置信息（properties、xml、yaml等）注册到配置中心，实现开发、测试、生产环境的包无差别，方便包的迁移。API管理：以方便的形式编写和更新API文档，供调用者查看和测试。集成框架：微服务组件以单一职责包的形式对外提供服务。集成框架将所有的微服务组件（尤其是管理组件）以配置的形式集成到一个统一的界面框架中，用户可以通过统一的界面使用系统。分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、尽力而为通知）来保证数据的一致性。调用链：记录一个业务逻辑完成时调用的微服务，并展示这种串行或并行的调用关系。当系统出现故障时，您可以轻松找到错误点。支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控都比单体架构复杂，因此大部分工作需要自动化。如今，可以使用Docker等工具来抵消这些微服务架构的缺点。比如持续集成，蓝绿发布，健康检查，性能健康等等。说真的，根据我们两年的实践经验，可以说，如果没有合适的支撑平台或者工具，就不要使用微服务架构.微服务架构的优势：降低系统复杂度：每个服务都比较简单，只专注于一个业务功能。松耦合：微服务架构是松耦合的，每个微服务可以由不同的团队独立开发，互不影响。跨语言：只要符合服务API契约，开发者可以自由选择开发技术。这意味着开发人员可以编写或重构服务以采用新技术，而且由于服务相对较小，因此不会对整体应用造成太大影响。独立部署：微服务架构使得每个微服务都可以独立部署。开发人员无需协调部署服务升级或变更。一旦测试通过，就可以部署这些更改。所以微服务架构也让CI/CD成为可能。Docker容器：与Docker容器结合使用效果更好。DDD领域驱动设计：符合DDD的理念，结合开发会更好。微服务架构的缺点：微服务强调服务的规模，但实际上并没有统一的标准：业务逻辑应该按照什么规则划分到微服务中，这本身就是一个实证工程。一些开发人员认为10-100行代码应该足以构建微服务。虽然构建小型服务是微服务架构所提倡的，但请记住，微服务是达到目的的手段，而不是目的。微服务的目标是将一个应用充分分解，便于敏捷开发和持续集成部署。微服务分布式特性带来的复杂性：开发者需要基于RPC或消息实现微服务之间的调用和通信，这使得服务之间的发现、服务调用链的跟踪和质量问题变得困难。相当棘手。分区数据库系统和分布式事务：更新多个业务实体的业务事务非常普遍，不同的服务可能有不同的数据库。CAP原则的约束迫使我们放弃传统的强一致性，转而追求最终一致性，这对开发者来说是一个挑战。测试挑战：传统的单体WEB应用只需要测试单个RESTAPI，而测试微服务需要启动它所依赖的所有其他服务。不能低估这种复杂性。跨多个服务的变更：比如在传统的单体应用中，如果有A、B、C三个服务需要变更，A依赖B，B依赖C，我们只需要改动对应的模块即可并一次性部署。但在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C，然后更新B，最后更新A。部署复杂：微服务由大量不??同的服务组成。每个服务可能有自己的配置、应用程序实例的数量和基本服务地址。这里需要不同的配置、部署、扩展和监控组件。此外，我们需要一种服务发现机制，以便服务可以发现与之通信的其他服务的地址。因此，微服务应用的成功部署需要开发者有更好的部署策略和高度的自动化。总的来说（问题与挑战）：API网关、服务间调用、服务发现、服务容错、服务部署、数据调用。微服务要解决的问题上面说了dubbo还存在一些问题。其实dubbo中的问题就是微服务要解决的问题。让我们在这里总结一下。当然，dubbo和微服务侧重点不同。Dubbo侧重于内部接口之间的RPC，而微服务侧重于对外提供服务。统一入口安全控制：防刷卡、限流统一认证：应用认证、用户认证、OAuth认证、ACL协议转换：http、dubbo、ProtobufAPI配置管理API在线、离线API和服务接口映射监控告警可扩展，高-并发、分布式服务容器自动收缩和扩容的整体架构。负载均衡层：nginx/lvs/F5微服务层高性能服务网关；统一入口、API配置管理、分发认证、服务监控、协议转换；API映射、OAuth2.0、API文档管理；分布式、可扩展；服务治理层成熟的服务治理框架dubbo；MQ服务之间的解耦；弹性云服务码头化；基于访问压力的集群实时调度与管理；弹性云这里简单介绍一下弹性云的概念。微服务需要对运维有很高的要求，才能提供好的服务，保证API不会挂掉，有好的性能。这里的弹性云是一种自动化运维方案，可以监控访问压力，并根据监控方案来调度应用的发布和回收。ServiceMesh2017年底，非侵入式ServiceMesh技术从萌芽走向成熟。ServiceMesh也译为“服务网格”，作为服务间通信的基础设施层。如果用一句话来解释什么是ServiceMesh，可以类比为应用程序或微服务之间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于写应用，一般不需要关心TCP/IP层（比如通过HTTP协议的RESTful应用），使用ServiceMesh也省去了那些原本通过应用或者服务实现的服务之间的东西其他框架。比如SpringCloud和OSS，现在可以交给ServiceMesh了。ServiceMesh的来龙去脉：从最原始的主机通过网线直接连接，网络层的出现，应用内部控制流的集成，到应用外部控制流的分解，集成应用程序中的服务发现和断路器用于服务发现和断路器的软件包/库，例如Twitter的Finagle和Facebook的Proxygen，此时仍集成在应用程序中。专门用于服务发现和断路器的开源软件，例如NetflixOSS、Airbnb的synapse和nerve最后，ServiceMesh作为微服务的中间层出现。ServiceMesh具有以下特点：应用间通信的中间层。服务发现ServiceMesh架构图：我对微服务和服务网格区别的理解：微服务更像是服务之间的生态系统，侧重于服务治理等方面，而服务网格更侧重于服务间的通信，以及更好的集成与DevOps。
