微服务架构现在是企业应用架构必谈的话题。微服务之所以火热，是因为它相比以往的应用开发方式有很多优势，比如灵活，更能适应当前需求快速变化的环境。本文将介绍微服务架构的演进、优缺点，以及微服务应用的设计原则，然后重点探讨作为“微服务应用平台”需要提供哪些能力和问题，才能更好地支撑企业应用架构。微服务平台也是我目前参与的一个平台产品，还在研发中。该平台基于SpringCloud，结合朴元多年对企业应用的理解和产品设计经验。一个正在逐步孵化的微服务应用平台。内容：1.微服务架构演进过程2.微服务架构的好处3.微服务应用的四大设计原则4.微服务架构带来的问题5.19微服务平台的实现实践6.总结与展望1.微服务架构的演进过程近年来，我们都体验到了互联网和移动互联网带来的好处。作为IT从业者，我们在生活中感受到互联网带来好处的同时，在工作中可能也会感受到一些来自互联网的压力。也就是我们传统企业的IT建设也迫切需要转型，需要面向外部客户。我们还需要应对外部环境的快速变化，需要快速创新。那么我们的IT架构也需要向互联网公司学习，做出相应的改进。支持企业数字化转型。我们先来看看应用架构的演进过程，回想一下微服务架构是如何一步步演进的。最早的应用是单体架构。后来为了有一定的扩展性和可靠性，出现了垂直架构，就是加了A负载均衡，接着就是前几年流行的SOA，主要讲的是应用系统之间如何集成互操作，而现在的微服务架构，就是进一步探讨如何设计一个应用系统，才能更好的开发和管理，更加灵活和高效。微服务架构的基本思想是“围绕业务领域组件创建应用，让应用能够独立开发、管理和加速”。2.微服务架构的优势我们总结了四个方面的优势，具体如下：每个微服务组件简单灵活，可以独立部署。不再像以前那样，应用需要庞大的应用服务器来支撑。一个小团队可以负责更专业专注，相应地更高效可靠。微服务是松耦合的，微服务内部是高内聚的，各个微服务很容易按需扩展。微服务架构与语言工具无关，您可以自由选择合适的语言和工具，高效完成业务目标。看到这里大家会觉得微服务架构挺好的，但是还有一些疑问，微服务架构的应用到底是个什么样的应用？如何设计微服务架构应用？来看看我们推荐的微服务应用设计原则。三、微服务应用的四大设计原则我们总结了四大原则推荐给大家：AKF拆分原则Front-endSeparationStatelessServiceRestfulCommunicationStyle1.AKF拆分原则AKFExpansionCube（参考《The Art of Scalability》），是一个一家叫AKF的公司的技术专家抽象概括了应用扩展的三个维度。理论上，按照这三种扩展方式，可以对单个系统进行全面扩展。X轴：指的是水平复制，很好理解。就是多跑几个单系统的实例，做成集群加负载均衡的模式。Z轴：基于相似的数据分区。比如一个互联网打车应用突然活跃起来，用户数量激增，集群模式无法支持，那么就按照用户请求的区域进行数据分区。集群。Y轴：也就是我们所说的微服务的拆分方式，是根据不同的业务进行拆分。场景描述：比如打车应用不能支持一个集群时，拆分成多个集群。后来用户激增还是不行。经过分析发现，乘客和车主的访问量较大，因此将打车应用拆分为三种乘客服务。、车主服务、支付服务。三个服务的业务特性不同，各自独立维护，各自可以按需再次扩展。2、前后端分离前后端分离的原则，简单来说就是前后端的代码分离，即技术分离。我们推荐的模式是直接物理分离部署，进一步促进更彻底的分离。不要延续之前的服务器端模板技术，比如JSP，把JavaJS、HTML、CSS堆在一个页面里，稍微复杂一点的页面就没法维护了。这种分离模式有几个好处：前后端技术分离，各自的专家可以针对各自的领域进行优化，这样前端的用户体验优化效果会更好。分离模式，前后端交互界面更加清晰，只剩下界面和模型，后端界面简洁易维护。前端多渠道融合场景更容易实现，后端服务无需改动。统一的数据和模型，可以支持前端webUI\手机App等的访问。3.无状态服务对于无状态服务，我们先来说说什么是状态：如果一个数据需要被多个服务共享完成一笔交易，那么这个数据就叫做状态。反过来，依赖于这种“有状态”数据的服务称为有状态服务，反之则称为无状态服务。那么这种无状态服务原则并不是说微服务架构中不允许有状态。表达的真正意思是将有状态的业务服务变成无状态的计算服务，然后将状态数据迁移到对应的“StatefulDataService”。场景描述：比如我们之前在本地内存中建立的数据缓存和会话缓存，在现在的微服务架构中，这些数据应该迁移到分布式缓存中存储，让业务服务成为一个无状态的计算节点。迁移后可以实现按需动态伸缩，微服务应用可以在运行时动态增删节点，无需考虑如何同步缓存数据。4.作为一个原则，Restful通信风格应该是“无状态通信原则”。这里直接推荐一种实践优化过的Restful通信方式，因为它有很多优点：无状态协议HTTP具有先天优势，可扩展性非常强。比如需要安全加密，有现成的成熟方案HTTPS。JSON消息序列化，轻量简单，人机可读，学习成本低，对搜索引擎友好。语言无关紧要。各大流行语言都提供了成熟的RestfulAPI框架，相比其他一些RPC框架生态更完整。当然，在一些特殊的业务场景下，还需要使用其他的RPC框架，比如thrift、avro-rpc、grpc等。但在大多数情况下，Restful就足够了。四、微服务架构带来的问题如果上面提到的四个原则都实现了，那么就可以说一个微服务应用已经搭建好了，而且感觉并不复杂。但实际上，微服务并不是万能的，有利也有弊。接下来我们来看看微服务架构的引入带来的问题。很难跟踪依赖服务的变化。其他团队的服务接口文档过时了怎么办？如果依赖服务没有准备好，我如何验证我开发的功能。有些模块是重复构建的，跨团队、跨系统、跨语言会有很多重复构建。微服务放大了分布式架构中的一系列问题，比如如何处理分布式事务？依赖服务不稳定怎么办？运维的复杂度急剧增加，例如：大量的部署对象和众多的监控进程导致整体运维复杂度的增加。上面的问题我们应该都遇到过，也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架；实现统一认证、统一配置、统一日志框架、分布式汇总分析；使用全局事务方案，使用异步模拟和同步；搭建持续集成平台、统一监控平台等。折腾了这些方案，终于想通了。原来我们需要一个微服务应用平台来整体解决这些问题。5.微服务平台的19个实践1.企业IT建设的三个基础环境。基础设施。团队协作环境：主要在DevOps领域，负责从需求到规划任务，团队协作，再到质量管理，持续集成和发布。个人基础环境：就是本文介绍的微服务应用平台。他的主要目标是支持微服务应用的设计、开发和测试，运行过程中的业务数据处理，以及应用的管理和监控。IT基础设施：就是我们通常所说的各种运行环境支持，如IaaS（VM虚拟化）和CaaS（容器虚拟化）等实现方式。2、微服务应用平台总体架构微服务应用平台总体架构主要从开发集成、微服务运行容器与平台、运行时监控与管理、外部通道接入等维度进行划分。开发集成：主要是构建一个微服务平台运行时需要的一些工具和仓库：需要一个微服务平台提供一些基础能力和分布式支持能力，我们的微服务运行容器会跑在这个平台上。监控治理：致力于对托管微服务在运行时的统一监控和配置。服务网关：负责与前端WEB应用、手机APP等渠道对接，对前端请求进行仔细鉴权，然后进行路由转发。3、微服务应用平台运行视图参考上图。在运营期，作为微服务架构的平台和业务系统，除了业务应用本身，还需要接入服务、统一门户、基础服务等平台级服务。保证业务系统的可靠运行。图中的公共服务是业务处理中需要用到的一些可选服务。4.微服务平台的设计目标微服务平台的主要目标是支持微服务应用从需求到设计、开发测试、运行过程中的业务数据处理、应用管理和监控的全生命周期管理。切入应用生命周期的几个重要阶段，结合上述设计原则和问题，介绍平台提供的能力支持。5.微服务开发：前端、后端、混合下面看一下我们正在开发的微服务应用平台EOS8.0的开发工具的一些截图，了解在开发过程中提供了哪些关键能力时期。前面的设计原则提到了一个前后端分离的原则，所以我们的开发环境目前支持前端项目、后端项目、混合项目的创建。其中，前端项目和后端项目对应的是前后端分离的原则。利用平台集成的开发工具和框架，可以实现前后端开发分离。使用持续集成工具可以很方便的将前后端项目编译打包成独立的程序运行。混合项目保留了与传统模型的兼容性，为企业应用向微服务架构演进提供了过渡方案。6.服务契约和API管理我们可以利用平台提供的API管理能力来解决上述微服务带来的依赖管理问题。说到API管理，首先要提到的就是服务契约。平台开发工具提供便捷的服务发布能力，可以快速对外发布业务功能，生成服务规范合约。当然你也可以先设计服务契约，然后根据契约生成服务的默认实现代码。在这里强调一下，我们提到的服务契约是一个非常重要的东西。有点类似于web服务的wsdl描述。主要描述了服务接口的输入输出规范以及其他与服务调用集成相关的规范。7.服务契约和服务模拟有了服务契约，我们可以根据契约自动生成服务文档和服务模拟测试环境。这样，开发者可以方便的获取依赖服务的变化，并可以及时的基于依赖服务。自行修改调整程序，并可方便地进行模拟测试验证。基于契约生成mock服务，也就是我们常说的服务挡板，这样即使我们依赖的其他服务无法提供功能，也可以通过挡板进行联调测试。8.服务契约与服务编排有了服务契约，就有了服务接口的输入输出规范，restful服务编排成为可能。在我们设计的合约标准中，我们也定义了调用集成相关的内容，比如服务支持的交易模式等等。通过这些约定，我们可以用简单的图形化方式编排业务服务流程。编排可以大大简化分布式服务调用的复杂度，同步、异步、异步模拟同步、超时重试、事务补偿等，都由服务编排引擎完成，不再完全依赖于服务编排的编码能力掌握。服务编排具有很大的作用和意义。可以快速组合和释放提供的微服务能力，非常适合快速的业务创新。但是大家要注意，逻辑流编排就是业务流程，尽量做到简单明了，业务含义一目了然。业务规则建议在服务内部编码实现。不要完全用我们的“逻辑流”图形化服务安排来代替程序编码，否则你可能会走向另一个极端，比如设计一个像蜘蛛网一样的逻辑流程图，那简直就是一场灾难。9、微服务容器我们来看一个微服务运行容器的逻辑图。可以看到我们需要应用微服务架构，可靠高效的微服务应用。其实我们还需要做很多事情。如果没有统一的微服务容器，这些能力就需要构建在各个微服务组件中，而且会千差万别，难以集成。有了统一的微服务运行容器和一些公共的基础服务，上述微服务架构下部分组件重复构建的问题也迎刃而解。10.第三方能力集成说明我们的API管理合约文档API模拟是一个集成了Swagger的工具链。微服务应用平台的基础是SpringCloud，它的能力用来支撑从容器框架到注册发现再到安全认证的基础解决方案。让我们简单了解一下我们集成的一些开源框架和工具。SpringCloud在微服务平台中的定位是基础框架。本文的重点是介绍企业级微服务平台实现过程中的一些设计原则和解决方案。SpringCloud相关的具体技术本文不做介绍。您可以在我们的公众号中查看相关文章。11、服务注册发现路由接下来说说注册发现。以前单块应用之间相互调用配置一个IP就可以了。但是在微服务架构下，服务提供者会很多，手动配置IP地址会发生变化。成为不可能。那么服务自动注册发现方案就解决了这个问题。我们的服务注册发现能力是依赖SpringCloudEureka组件实现的。当服务启动时，它会将自己要发布的服务注册到服务注册中心。运行时，如果需要调用其他微服务的接口，必须先去注册中心获取服务提供者的地址。拿到地址后，在微服务容器内部通过一个简单的负载均衡周期进行路由。一般情况下，系统中微服务的调用都是通过这种客户端负载方式进行的，否则需要很多负载均衡过程。跨业务系统的服务调用也可以采用这种去中心化的路由方式。当然，采用SOA模型，有一个集中的服务网管来管理系统间的调用也是一种选择，需要结合企业的IT现状和需求来确定。12、统一认证在安全认证方面，我们使用SpringSecurity结合Auth2和JWT（Jsonwebtoken）作为安全令牌，实现统一的安全认证和鉴权，实现微服务的隔离和安全的按需互通。在统一认证和权限方面，我们的产品会逐步推出比较完善和可扩展的微服务组件，可以作为微服务平台的公共认证和鉴权服务。再次强调，鉴权认证必须是公共服务，而不是多个系统单独搭建。13、日志和日志设计作为微服务应用平台，除了提供支持开发和运维的技术组件和框架外，我们还提供一些对运维友好的经验总结。让我们来看看我们推荐的日志和日志实现。我们先看日志。平台默认提供三种主要的日志类型，系统日志、引擎日志和跟踪日志。有了这些日志，就可以帮助我们在出现问题的时候获取一些关键的信息来定位问题。如果要追根溯源，右边这些序号的设计也很重要。结合日志和各种序列号，我们可以快速定位到问题发生的具体时间、地点和相关信息，并快速修复。业务交易全链路。这些日志和流水的详细处理，对于定位系统运维问题很有帮助。没有这些有用的日志内容，就算ELK日志收集套件建得再漂亮，收集一对垃圾日志也是白搭。通常开源框架只是提供一个框架供开发者自由发挥，但在设计平台时，必须考虑直接提供统一规范的基础能力。14、微服务的集中配置和管理在分布式环境下，一个系统被拆分成很多微服务，因此我们必须告别在生产或运维中手动修改配置配置的方式。需要集中的配置管理来提高运维效率。配置文件主要包括运行前的静态配置和运行中的动态配置。静态配置通常在编译部署包之前设置。动态配置是指系统运行过程中需要调整的系统变量或业务参数。要实现集中配置管理，需要注意以下几点。就是配置和媒体的分离，需要通过制定规范来控制。请勿将配置放在Jar包中。配置方式要统一，格式、读写方式、变更热更新方式尽量统一。采用统一的配置框架，就是要有一个配置中心，在运行时统一管理业务系统中的配置信息。这就需要一个平台来提供配置中心服务和配置管理入口。15.统一管理门户的微服务架构下，将一个大型EAR、WAR应用拆解成多个可独立运行的小微服务程序。通常，这些微服务程序不再依赖于应用服务器，如果不依赖于传统的应用服务器，应用服务器再提供一个管理控制台也是没有用的，所以微服务的运行时管理需要一个支持统一管理门户。我们规划的统一集中的微服务入口，可以支持应用开发、业务处理、应用管理、系统监控等。上图是应用管理页面，传统意义上就是管理我们的业务系统。点击一个业务系统，我们可以看到该系统下有哪些微服务。每个微服务都有若干节点实例运行，可以监控微服务子节点的状态，对微服务进行配置管理和监控。16、分布式事务问题在微服务架构的系统下，进程数成倍增加，因此分布式事务一致性问题也更加明显。我们这里说的事务一致性不是传统的基于数据库实现的技术事务。微服务是独立的，调用协议是无状态的，所以数据库事务方案从一开始就不在我们的考虑范围之内。我们需要解决的是在一定时间后，数据达到最终的一致状态。准确的说，是采用传统的业务补偿和修正方式。推荐的事务一致性方案有以下三种：可靠事件模式：即事件的发送和接收保证高可靠性，以实现事务一致性。补偿方式：确认取消，如果确认失败，将按倒序全部取消。TCC模式：TryConfirmCancel，补偿模式的一种特殊实现，通常用于转账交易。17、分布式同步调用问题微服务架构下，分布式调用比传统的部署方式多，所以“如何在不确定的环境下交付某些服务”可以简单理解为，当我所依赖的服务的可靠性无法满足时得到保证，如何保证自己能正常提供服务，不被依赖的其他服务拖累？我们推荐使用SEDA架构来解决这个问题。SEDA:stagedevent-drivenarchitecture本质上是一种采用分布式事件驱动模型，使用异步模拟进行同步，非阻塞等待，资源分配隔离的解决方案。18、持续集成和持续交付设计在运维方面，我们首先要解决的就是持续集成和持续交付。微服务应用平台的职责范围目前规划只做持续集成，方便使用持续集成环境将程序编译成媒体包和部署包。（目前计划的持续部署由DevOps平台提供，微服务平台可以与DevOps平台集成。）这里需要明确一个概念：介质是源代码编译的产物，与环境无关.多环境共享，如：jar、dockerfile；配置：是与环境相关的信息。配置+媒体=部署包。获取到部署包后，微服务应用平台的职责就完成了，接下来就是运维人员大显身手，进行线上部署操作了。19、微服务平台、容器云、DevOps的关系就微服务应用平台本身而言，不依赖于DevOps和容器云。开发的部署包可以运行在物理机、虚拟机或容器上。但是，当微服务应用平台将DevOps和容器云结合起来的时候，我们会发现持续集成和持续交付变成了一个非常简单、方便、可靠的过程。只需几个简单的步骤，即可搭建起整个开发、测试、预发布或生产环境。整个过程的复杂性被平台屏蔽了。通过三个基础环境的融合，我们可以让分散的微服务组件更加简单方便，统一管理和运维交付。6.总结与展望让我们回顾一下三个基本环境之间的关系。微服务应用平台负责应用的开发、运营和管理；DevOps负责项目管理、计划管理、CI、CD以及团队沟通协作；容器云平台负责基础设置管理，屏蔽环境的复杂性。这三个基础环境的建设直接反映了企业IT能力的高低。这三个基本环境是技术人员和企业都希望拥有的。它们是企业赢得竞争和驱动业务创新的基础，是企业加速数字化转型的必由之路。***，让我们来看看朴元正在开发的新一代ThePlatform。上图红框中的内容就是我们今天分享的微服务应用平台相关的部分。整个ThePlatform平台是我们站在企业整体架构规划的角度，从多个维度出发。目标是为企业构建可持续发展的IT生态环境，加速企业数字化进程。作者简介郝艳峰现任普源SOA&云计算产品部产品架构师。主要负责浦源流程产品的核心架构设计和产品版本开发规划，曾参与国网BPM、BAM平台、浦发银行新一代流程平台等大型平台项目的建设与实施
