微服务应该怎样服务后端业务系统？资源-CSDN文库

39 浏览量 2021-02-25 23:45:45 上传评论收藏 459KB PDF 举报

资源推荐

资源详情

资源评论

微服务应该怎样服务后端业务系统？微服务应该怎样服务后端业务系统？

“微服务化一词近来热度十足，是人云亦云还是确有两把刷子，本文从三个部分为您详解微服务化改造。

1业务系统：看似简单实则复杂

业务系统是任何一个用户产品的必须组成，充当着一个门面的角色，用户的输入就是这个系统需要维护的，数据存取是整个系

统的核心。例如，广告业务系统的输入是广告主的投放约束、定向条件，微博业务系统的输入是短文字、图片等。

在应用发展初期或者规模不大的情况下，有非常简单的实现方案，LNMP、JSP、PyWeb都是你能随口说出来的词，如果用某

种架构方式来描述，那就可以称做单体模式（Monolithic，Martin Flower大神所提出的，后面还会介绍），而这些技术都是单

体模式的成熟解决方案，它们可以使你工作在“应用层”的最顶端，各种中间件、框架能让你省心地干好业务，开发人员可以通

过“模块化”的手段来管理业务系统的复杂度，使他们之间解耦、复用。简单来说，这个单体就是如下这种层次划分。

看起来很简单，对吧。诚然，业务系统在这里面还需要做很多，比如缓存、SQL优化、数据分区、系统安全工作，当然还有对

于代码的维护和重构。这种工作方式可以很好的工作几年、甚至十年，但是如果业务发展非常快，在系统复杂度、业务规模、

参与人数、代码腐化程度都不断上升的情况下，你会发现整个项目正陷于泥潭，PM/RD/QA/OP经常抱怨：

“改个小功能，怎么要拉这么多模块？”

“拉模块也就罢了，改的地方多，编译太慢了。”

“慢也就算了，关键不知道怎么改，这代码太丑陋了，算了，为了满足PM的排期需要，凑合来吧。”

“凑合来了，QA发现bug，返工再返工，延期再延期。”

“上线了，oh my god，报case了，性能有问题，原来是依赖的模块访问数据库用了for循环select。”

透过现象看本质，我总结就这三点问题：

1、业务逻辑复杂耦合，开发维护成本高

系统复杂度、规模、参与人数都和腐化程度成正比，单纯的靠模块化，后期来看会存在个别模块成为”大怪物“，臃肿不堪，粒

度过粗，难以复用。

2、交付效率和质量低

在敏捷和持续集成方法论、实践大行其道的现今，迭代的按期交付率、单测覆盖率都不尽如人意，线上问题频发。

3、非功能需求不达标

非功能需求指标特指性能、可用性、可扩展性等方面，代码的腐化和缺少维护、重构，以及没有代码洁癖的人污染下，必然导

致性能逐渐下降，甚至出现不同资源竞争的短板效应，造成整个系统crash，同时一个大怪物的伸缩性较差，不能随意横向扩

展某个细分功能点。

我想任何人做架构都需要秉承“业务需求决定技术演化路线”的思路，那么这些暴露出来的现状和问题都驱动系统去转型，在系

统和人之间找到一种最佳的合作模式，匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Beck所说的：

“Design is there to enable you to keep changing the software easily in the long term” ，即“变化发生时设计被破坏的程度”。

放眼业界，面对复杂的、大规模的、多人协作完成的业务系统，如何管理好这个复杂度，有很多方法，模块化、OSGI、传统

服务化SOA等等，当今最佳实践的趋势还是服务化，而微服务是最近火热起来的概念，有些人肯定觉得这不就是炒作嘛，但

是不管黑猫白猫能抓耗子就是好猫，所以解决问题是重点，不要刻意去批评一些名字，那么本文要重点介绍的就是——如何做

微服务化转型和改造。

在接下来讲之前，要重点声明，本文并不是推崇服务化，不鼓励单体模式，相反而是相当肯定和支持单体模式，它模块依赖简

单、一个发布包、部署于一个容器都使得构建应用非常的简单，在体量还不大的情况下，首先应该解决的是搭建好一套绝对稳

定的基于模块化的平台，待体量逐渐长大，再去根据实际需要进行拆分，团队也随之变化（facebook的单体持续了非常长的

时间，一是人员素质高，二就是基础平台建设的非常好）。再下个阶段体量大到饱受单体模式之苦，也应该先建设平台化服

务，建设好之后，先按照大的粒度进行拆分，逐步再微服务化，否则，直接上服务化、甚至下面要说的微服务都是非常危险

的，鲜有成功案例。

2微服务改造

做改造一般要经历三个步骤：

第一、技术选型决策

第二、架构设计规划

第三、落地实施应用。

下面依次展开三个部分，重点介绍前两个步骤，有了这两个，落地应用也就顺水推舟的好做了。

一、技术选型决策

1.选择微服务化方式

选择服务化，众所周知就是SOA嘛，这是一种架构风格，重点在原则、理念、方法论等高思维层次上，对于工具、框架、解

决方案没有做强制限制，ESB、websercie（基于WSDL和SOAP/BPEL）这两种是企业中流行的，也是过去一直引领SOA的

技术领头羊，但是随着互联网应用的发展，在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高，传统的SOA并

不适合这种场景。那么，现在的互联网流行的实现方式是什么呢？一种最佳的实践方式就是微服务化（Micro Service）。

微服务就是一种SOA的实现方式而已，更加侧重于在服务的细分演化，是指引服务的具体落地方案层面的一种实践方式。过

去很多互联网公司在实践，你可以把淘宝的dubbo、HSF，navi-rpc服务化框架看做比传统SOA更适用、更贴近微服务化实现

的服务化框架，依赖这些框架可以方便的做服务化。这个趋势被Martin Flower大神所发现，并且提出了，你们这些不都是在

做“微服务”嘛。

Martin对微服务这个术语（terminology）的解释是：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services,

each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These

services are built around

business capabilities and independently deployable by fully automated

deployment machinery. There is a bare minimum of centralized management

of these services, which may be written in different programming

languages and use different data storage technologies.

简而言之，微服务化就是以一系列小的服务来开发支撑一个应用的方法论，服务独立在自己的进程中，通过轻量级通信机制交

互（通常是走HTTP协议）。这些服务是围绕着业务上的组织结构来构建的，全自动的、独立部署。几乎看不到中心化的服务

管理基础设施，可以使用不同的编程语言和数据存储技术来实现不同的服务。

在简单的一种理解来自于一本书《Building Microservices》（Sam Newman, O’Reilly Media），Microservices are

small,autonomous services that work together. 微服务化就是一堆小而自治的服务，让他们一起工作起来。

相比于传统的SOA，Martin的总结特点可以参考他的博客还有视频，一共是9个特点，这里不想赘述，而是说说我个人的理

解，微服务化的特点在于：

剩余7页未读，继续阅读

评论收藏

内容反馈

weixin_38694566

粉丝: 5
资源: 878

微服务应该怎样服务后端业务系统？

后端业务系统的微服务化改造.docx

十次方微服务架构前端和后端

产品经理不用写代码也能实现后端微服务开发？飞算全自动软件工程平台来了.docx

产品经理不用写代码也能实现后端微服务开发？飞算全自动软件工程平台来了.pdf

与《凤凰架构》中单体、微服务、无服务的后端工程搭配的前端示例代-fenix-bookstore-frontend.zip

基于spring cloud微服务架构的实验教学管理系统后端

hdw-dubbo 微服务化开发平台，具有统一授权、认证后台管理系统，其中包含具备用户管理、资源权限管理等多个模块，支持多业务系统并行开发，可以作为后端服务的开

若依微服务版前后端分离系统.rar

仿百度网盘的一款轻量级微服务架构网盘系统，云盘系统，文件管理系统

微服务架构下的信贷系统设计

谈谈后端业务系统的微服务化改造

GoView Go后台服务，基于gozero微服务框架实现后端接口。.zip

基于微服务架构的客户关系管理系统的研究.docx

(完整版)基于SpringCloud微服务系统设计方案.pdf

(完整版)基于SpringCloud微服务系统设计方案.docx

7.仿若依后端系统业务实践文章实践代码

基于SpringCloud-微服务系统设计方案 2020最新.docx

微服务架构-服务网关.docx

微服务网关后端配套代码-go_gateway.zip

基于Scala的微服务架构后台服务设计源码 - biBACK

毕业设计后端-基于springcloud微服务和区块链的志愿服务平台.zip

pizzeria-backend：使用微服务的披萨任务的后端

微服务后端

基于微服务架构，包括健康社区业务、体检预约业务和肺癌AI风险评估业务，帮助大众维护身体健康 应用技术：后端：SpringBoo

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

最新资源

基于微服务架构，包括健康社区业务、体检预约业务和肺癌AI风险评估业务，帮助大众维护身体健康应用技术：后端：SpringBoo

Qt 5实现串口调试助手（源工程文件、0积分下载）