微服务设计与解决方案

《微服务设计与解决方案》由会员分享，可在线阅读，更多相关《微服务设计与解决方案（18页珍藏版）》请在金锄头文库上搜索。

1、1.1.1.1.1.1.1微服务设计与解决方案微服务架构现在是谈到企业应用架构时必聊的话题，微服务之所以火热也是 因为相对之前的应用开发方式有很多优点，如更灵活、更能适应现在需求快速变 更的大环境。本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则，然后着重介绍 作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企 业应用架构。微服务平台也是我目前正在参与的，还在研发过程中的平台产品，平台是以 SpringCloud为基础，结合了普元多年来对企业应用的理解和产品的设计经验， 逐步孵化的一个微服务应用平台。目录： 一、微服务架构演进过程二、微服务架构的好处三、微服务应用

2、4个设计原则四、微服务架构带来的问题五、微服务平台的19个落地实践六、总结展望一、微服务架构演进过程俺统应用-服潞部客户和念作耕伴露求变动快叫雌甲，取和泠放 9布式避彳七，切制M零开始,业务与 打王法归开.需耍恨速削诂远用妃模斐优大 ,大范匡I广说鹃漠述. 易夫遮（漩：），对业凳律曜、住逸腹 布更求圈眼彰内都用户为主,痢求明痛，胡能全，温疝广大 集成，中趣制，适含稽定发展刖性强,雄以供速变比.雄护成 本商,快速交单的新业态无去支近年来我们大家都体会到了互联网、移动互联带来的好处，作为IT从业者，在 生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一 些压力，那就是我们传统企

3、业的IT建设也是迫切需要转型，需要面向外部客户， 我们也需要应对外部环境的快速变化、需要快速创新，那么我们的IT架构也需 要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产 生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直 架构，也就是加了个负载均衡，接下来是前几年比较火的SOA，主要讲了应用 系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系 统该如何设计才能够更好的开发、管理更加灵活高效。微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立的 开发、管理和

4、加速”。二、微服务架构的好处我们总结了四个方面的优点，分别如下:是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应 用需要一个庞大的应用服务器来支撑。可以由一个小团队负责更专注专业，相应的也就更高效可靠。微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需 扩展。微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业 务目标即可。看到这里，大家会觉得微服务架构挺不错，然而还会有一些疑问，什么样的应用 算是一个微服务架构的应用？该怎样设计一个微服务架构的应用？那我们来一起 看看我们推荐的微服务应用的设计原则。三、微服务应用4个设计原则我们总结了四个原则推荐给大

5、家: AKF拆分原则前后端分离无状态服务 Restful通信风格1. AKF拆分原则AKF扩展立方体（参考The Art of Scalability），是一个叫AKF的公司的技术 专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个 单体系统，进行无限扩展。X轴：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集 群加负载均衡的模式。Z轴：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激 增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、 四川等多建几个集群。Y轴:就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。场景说明

6、：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还 是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘 客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自 都可以再次按需扩展。2. 前后端分离前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我 们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分 离。不要继续以前的服务端模板技术，比如JSP，把Java JS HTML CSS都堆到 一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：前后端技术分离，可以由各自的专家来对各自的领域进行优化，这

7、样前端 的用户体验优化效果会更好。分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接 口简洁明了，更容易维护。前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和 模型，可以支撑前端的web UI移动App等访问。3. 无状态服务 对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享， 才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务 被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真 实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就 相应的迁移到对

8、应的“有状态数据服务”中。场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在 的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一 个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时 动态增删节点，就不再需要考虑缓存数据如何同步的问题。4.Restfu通信风格作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实 践优选的Restful通信风格，因为他有很多好处：无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是， 有现成的成熟方案HTTPS可用。 JSON报文序列化，轻量简单，人与机器均可读，学

9、习成本低，搜索引擎 友好。语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一 些RPC框架生态更完善。当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、 grpco但绝大多数情况下Restful就足够用了。四、微服务架构带来的问题做到了前面讲的四个原则，那么就可以说是构建了一个微服务应用，感觉上也不 复杂。但实际上微服务也不是个万金油，也是有利有弊的，接下来我们来看看引 入微服务架构后带来的问题有哪些。依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办?依赖的服 务没有准备好，如何验证我开发的功能。部分模块重复构建，跨团队、跨系

10、统、跨语言会有很多的重复建设。微服务放大了分布式架构的系列问题，如分布式事务怎么处理?依赖服务 不稳定怎么办？运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提 升。上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、 服务治理、服务模拟的工具和框架；实现统一认证、统一配置、统一日志框架、 分布式汇总分析；采用全局事务方案、采用异步模拟同步;搭建持续集成平台、统 一监控平台等等。这些解决方案折腾到最后终于搞明白了，原来我们是需要一个微服务应用平台才 能整体性的解决这些问题。五、微服务平台的19个落地实践1. 企业IT建设的三大基础环境我们先来宏观的看一下，一个

11、企业的IT建设非常重要的三大基础环境：团队协 作环境、个人基础环境、IT基础设施。团队协作环境:主要是DevOps领域的范畴，负责从需求到计划任务，团队协 作，再到质量管理、持续集成和发布。个人基础环境:就是本文介绍的微服务应用平台，他的目标主要就是要支撑微 服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。IT基础设施:就是我们通常说的各种运行环境支撑如IaaS （VM虚拟化）和CaaS （容器虚拟化）等实现方式。2. 微服务应用平台总体架构微服务应用平台的总体架构，主要是从开发集成、微服务运行容器与平台、运行 时监控治理和外部渠道接入等维度来划分的。开发集成:主要是搭建一个微服

12、务平台需要具备的一些工具和仓库运行时:要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微 服务运行容器则会运行在这个平台之上。监控治理:则是致力于在运行时能够对受管的微服务进行统一的监控、配置等 能力。服务网关：则是负责与前端的WEB应用移动APP等渠道集成，对前端请求 进行认真鉴权，然后路由转发。3. 微服务应用平台的运行视图参考上图，在运行期，作为一个微服务架构的平台与业务系统，除了业务应用本 身外，还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的 可靠运行。图中的公共服务就是业务处理过程中需要用到的一些可选服务。4. 微服务平台的设计目标微服务平台的主要目标主要

13、就是要支撑微服务应用的全生命周期管理，从需求到 设计开发测试，运行期的业务数据处理和应用的管理监控等，后续将从应用生命 周期的几个重要阶段切入，结合前面提到的设计原则和问题，介绍平台提供的能 力支撑情况。5. 微服务开发：前端、后端、混合我们一起看一下我们正在开发中的微服务应用平台EOS8.0的一些开发工具截图， 了解一下开发期提供了哪些关键的能力支撑。前面的设计原则中提到了一个前后端分离的原则，那么我们的开发环境中，目前 支持创建前端项目、后端项目和混合项目。其中前端项目、后端项目就对应前后 端分离的原则，利用平台中集成的开发工具和框架可以做到前后端开发分离，利 用持续集成工具可以方便的将前

14、端、后端项目编译打包成可独立运行的程序。混 合项目则是为了兼容传统模式而保留的，为企业应用向微服务架构演进提供过渡6. 服务契约与API管理对于前面提到的微服务带来的依赖管理问题，我们可以通过平台提供的API管 理能力来解决。说到API管理，那首先就用提到服务契约。平台开发工具中提 供了方便的服务发布能力，能够快速的将业务功能对外发布，生成服务的规格契 约，当然也可以先设计服务契约，在根据契约来生成服务的默认实现代码。这里强调一下，我们提到的服务契约是一个很重要的东西，他有点类似 web service的wsdl描述，主要描述服务接口的输入输出规格标准和其他一些服务调 用集成相关的规格内容。7

15、. 服务契约与服务模拟有了服务契约，我们就可以根据契约自动生成服务的文档和服务模拟测试环境， 这样，开发者就可以方便的获取到依赖服务变更的情况，能够及时的根据依赖服 务的变化调整自己的程序，并且能够方便的进行模拟测试验证。根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还 无法提供功能，我们也可以通过挡板来进行联调测试。8. 服务契约与服务编排有了服务契约，那就有了服务接口的输入输出规格，那么restful的服务编排也就 变得可行。在我们设计的契约标准中，还定义了调用集成相关的内容，比如服务 支持的事务模式等等。通过这些约定，我们就可以采用简单图形化的方式来对业 务服务流程进行编排。编排能够很大程度上简化分布式服务调用的复杂度，如同 步、异步、异步模拟同步、超时重试、事务补偿等，均有服务编排引擎完成，不 再完全依赖老师傅的编码能力。服务编排的作用和意义很大，可以快速的将已经提供的微服务能力进行组合发布， 非常适合业务的快速创新。但是大家要注意，逻辑流编排的是业务流程，尽量能够简单明了，一眼看上去就 明白业务含义。而业务规则推荐采用服务内部进行编码实现。千万不要将我们的 “逻辑流”图形化服务编排完全取代程序编码，这样就会可能会走入另外一个极 端，比如设计出像蜘蛛网一样的逻辑流图，简直就是灾难。9. 微服务容