40 | 服务端的业务架构建议
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文主要讨论了服务端的业务架构建议，重点关注了服务端程序的网络协议和授权方式。作者首先介绍了服务端程序的体系架构，将其分为 Multi-User Model 层和 Web 层，并强调了RESTful API的重要性。在网络协议方面，RESTful API被认为是事实上的网络API定义规范，而授权方面则介绍了基于Token和AK/SK的两种主流授权方式。文章强调了RESTful API的简洁明了和易于实施，同时也提到了其他选择，如基于XML的SOAP和WSDL，以及基于二进制的协议。在授权方面，OAuth 2.0被推荐用于面向终端用户的场景，而AK/SK授权多发生在面向企业用户提供API的场景。总的来说，文章强调了服务端程序的网络协议和授权方式的选择，以及如何构建业务无关的用户帐号体系和授权系统。 文章还介绍了一些相关的框架和工具，如grpc框架和restrpc服务器框架，以及httptest框架，这些工具可以帮助开发人员更好地实现业务API和进行单元测试。此外，文章还提到了存储中间件的选择问题，指出其与具体业务特征相关，将在后续实战案例中进行探讨。 总的来说，本文涵盖了服务端业务架构相关的通用问题，包括网络协议、授权、RPC框架、单元测试等，为服务端开发人员提供了一些实用的建议和工具。文章以技术性强、实用性强为特点，适合对服务端开发感兴趣的读者阅读。
《许式伟的架构课》，新⼈⾸单¥68
全部留言(12)
- 最新
- 精选
leslie许老师对存储和架构的理解确实不一样：开始学时还有些诧异为何只有此门功课的课程之间间隔相对较大；一路学来一路梳理，每次学完都会觉得有些疏漏需要自己去补；最终发现其实讲的太快根本无法理解所学的知识。 最初的学习目的是因为当下的数据系统和中间件有问题：之前自己在其它电商和金融业的经验无法移植，虽然系统放在云上，可是还是有性能问题，刚好老师的课开课，就带着求知欲来学习；课程开课到现在5个月了，学习老师的课程之余带着困惑把相关的知识顺带把相关知识梳理了一遍，前几天刘超老师的操作系统跟完了；自己把部分最关心的知识再看第二遍时才理解老师的讲解。最终发现某些困惑是因为自己的理解不够深度和广度，深度和广度铺开了且研究了有些东西就明白了；还有就是其实业界一直有个问题，对于某些知识/系统的标准划分其实蛮混乱的，这同样造就了典型问题本质相同的东西会因为包装不同而被叫成2种东西，不知道老师是否有这种体会？我自己作为一个一直混迹于中小企业近10年的DBA兼OPS对此深有体会。 关于存储中间层：其实这个定义老师应当是从物理层去划分的吧？其实关于这块选型我一直在研究存储中间层的选型：最近更是用了1个多月完全钻在里面，翻阅了不少书籍和看了一些极客时间里面其它老师的课，其实从设计层而已我们可以称为"数据系统"-这个概念其实是源自蔡超老师推荐的一本书籍中看到的;这个名词学生觉得更贴切-至少是设计层，无论是RMDB、NOSQL DB、MQ核心都是以数据为中心，他们的发展历程其实完全依赖的是硬件的发展-尤其是MQ。 根据发展历史其实关系型和非关系型的概念其实是同时提出：不过由于历史原因以及硬件原因，RMDB首先发展起来了，NOSQL DB的发展源自内存的代价不再那么庞大，随着服务端的模式的改变以及分布式设计的出现MQ开始彻底出现；故而现在其实三者是相辅相成，老师今天提出API，其实差的系统都有一点共性：API写的很差，RMDB、NOSQL DB、MQ的读写比例、调度机制设计的再合理扛不住一个烂的API的一个操作，前段时间公司某套系统内测时就碰到过接口程序写的太烂直接把数据库和操作系统资源跑崩的情况。 其实我现在非常好奇的是一件事情不知道许老师是否有所关注：其实现在很多的瓶颈已经从过去我们设计数据系统/存储中间件时硬盘、内存变成了CPU，AI 的聚焦其实一定程度上同样在CPU上：毕竟它有20年没有真正提升了，内存的廉价化其实已经让过去的数据库+数据仓库变成了NOSQL DB+ RMDB，CPU未来的提升会给现在的系统再次带来怎样的变化？ 今天是教师节：谢谢老师一路来的辛勤付出，祝愿老师节日快乐。作者回复: 这本书没法承担太多职能，我们的讨论重心始终会在架构，包括基础架构和业务架构。从架构角度来说，系统的瓶颈永远是存储中间件。但是从数据分析角度来说，CPU的确是我们的智能能够走得有多远的瓶颈。
2019-09-1031
TryTs许老师您好，我现在有个很天真的想法，不知道是否正确，在没有进入公司的情况下，在计算机行业里面如果实力真的足够（或者就是把所以硕士要求的课都学好），可否打破那种（要求硕士）的门槛的要求，还是说现状是不管怎样，必须先有那个硕士文凭在？作者回复: 文凭重要但又没有那么重要。硕士要求的课都“学好”和有实力也不完全等同，有实力可以有很多证明方式，用文凭可能是最没有说服力的证明方式之一。
2019-09-1710
Longerian我还是没明白，上图中Session-based Model 层和 Session-based ViewModel 层，对外提供的Web API 难道不也是 Restful API吗？为什么只强调“Multi-User Model 层，一般情况下它对外提供了一套 RESTful API 接口”作者回复: Web API 通常是基于 session 的，session 是一种状态，所以不是 RESTful（强调无状态）的。
2020-02-175
不温暖啊不纯良restful 风格请求的确很好用，它是对请求最简单的描述。 rpc是远程过程调用，其中有三个条件，一是协议要统一，二是路由要知道，三是序列化和反序列化。我理解的rpc和spring cloud 中的feign解决的问题一样，大家的业务都很内聚，当我需要你的业务功能支持的时候我就需要远程调用你的业务功能，最常见的场景就是用户认证，如果是一个微服务架构的系统，每一个微服务都要基于用户来做操作，第一步便是用户认证，接下来需要用到用户的某个功能时，就向用户管理的微服务发送请求，来完成步骤。 单元测试写起来很麻烦，特别是功能催得紧的时候，测试类都不想建，过一段时间，修改bug或需求的时候，改东边西边出了问题，改好一个小问题，改出一个大问题，而且还是部署上线后才能发现的……今天写了俩接口，类、方法、行代码的单元测试覆盖率百分百，第一次这么认真的写测试类，体会到了写完代码信心满满的感觉，而且是用我理解的厚model层设计的接口，整个代码看起来简洁了很多，今天对单元测试有更深的体会，它的存在起到一个及时反馈的作用，让你更早的发现问题，让你提交的代码质量更高。写的过程中还遇到一个困扰，就是程序如果依赖数据库，测试的效率就很低。作者回复: 数据库一般要不mock，要不就真跑一个实例（后者居多）
2021-04-252
Quincy老师，我想请教下老师一个建议，Devops想选一门专精的话，是专go语言还是Python比较有前或"钱"途作者回复: 都有前途
2019-09-202- Sam老师，麻烦问下Session-base model作为web api，是否他是融合多个后端业务系统的RESTful api后，提供给前端使用的web api接口吗？
作者回复: 是的
2019-09-152 
八哥还有很多前端工程师不知道在同域下，浏览器默认携带cookie，很多工程师理不清单点登录。认证这块可以多讲讲作者回复: 实战有一篇专门是认证篇
2019-09-122
pines如果一个服务需要c端用户为登录状态进行操作，例如淘宝或者京东，那么这个服务必然要维护session ，所以这个服务就不符合Rest规则了吗？Rest仅仅是数据接口？作者回复: 登录的session一般通过cookie来记录session id，在服务端记录session信息，这的确不那么无状态。不过authorization很特殊，通常不作为rest与否的判断依据。
2019-09-112- Geek_88604f但是从状态转化角度来说，桌面程序和服务端程序很不一样。桌面程序的状态转化往往存在中间的 “临时状态”，这其实也是 Controller 层的价值所在。关于这段描述有如下疑问，望解答: 一，理论上应该存在四种选择:桌面程序有临时状态、桌面程序无临时状态、服务端程序有临时状态、服务端程序无临时状态，而实际上只有桌面程序有临时状态、服务端程序无临时状态两种。究竟是什么样的需求或技术发展背景导致只有这两种情况？ 二，服务端对外暴露的api在内部也可能涉及到对多个其他服务的调用，在这个过程中也有可能产生临时状态。这个和老师的描述似乎不太一致，是否是我理解有误？
作者回复: 内部有临死状态那是内部的事，从交互接口来说没有临时状态。另外服务端内部临时状态一般通过事务来完成原子化，以避免出现不一致的状态。
2019-09-111 - Caffeine现在物联网这么火 不知道有没有针对嵌入式软件或单片机软件开发的架构设计呢
作者回复: 和桌面开发差不多，由于交互少，整个体系只会比桌面简单。
2019-09-101
