materialuiphp技巧_CTO之瞳后端系统1代码框架微做事初探

文章目录 [+]

范围这么广，很多领域都没打仗过，那写什么好呢？实在挺大略，打开猎聘找下CTO/架构师/研发总监之类的职位，看看职位哀求里都写了些什么，答案就跃然纸上了。

（图片来自网络侵删）

Java，spring boot，基于spring cloud的后端微做事体系，便是此部分的主角了。
每一种技能都有自身的利害势，每一个技能人选择什么技能栈都有自己的判断。
主要的不是选了什么，而是选择往后坚持走下去。
在技能的领域里，须要广度，同时更须要深度。

注：这里的广度，指的是可以端到真个完成一个业务体系搭建，也便是常说的全栈技能。
并不是指什么都摸两下，比如做前真个，本日用vue，来日诰日用react，后天又换成angular；做后真个本日java，来日诰日php，后天nodejs，这不能称之为广度。
当然，大神除外。

实在选什么开拓措辞，用什么技能框架与体系，这些也并不主要；主要的是：按照市场以及用户的需求，在合理的本钱与韶光范围下，搭建出可持续发展的技能系统。

正式开始吧。

1 代码框架

前面扯了一大段顶层的东西，为什么要从代码框架开始提及？由于良好的代码框架对应的是良好的逻辑分层，而技能里的分层实际上是一种形式的社会分工。
亚当斯密在《国富论》里曾经写到过：“劳动生产力最大的改进，以及劳动在任何地方运作或运用中所表示的技能、闇练和判断的大部分，彷佛都是劳动分工的结果。
”

先上代码（没有代码、系统框图、流程图的技能类文章都是耍泼皮，相反的，大段复制粘贴代码的技能类文章也是耍泼皮 ^^）。

https://github.com/ctoeyes/basicweb-ui

https://github.com/ctoeyes/basicweb-service

搭建了一个大略的web注册与登录demo，后端基于Springboot，前端基于React+MaterialUI，数据库MySql。
可以访问www.ctoeyes.cn查看效果，喷鼻香港的做事器，速率较慢。
主域名www.ctoeyes.com还在备案审核中，一旦审核通过，会把demo迁移过去。

Demo非常大略，没用https，数据库连接的密码是明文存储，API也没防暴力攻击，紧张用来解释代码框架。
不才一篇后端系统2里，从单体demo改为微做事demo时，这些点都会逐一改造。

这个后端service的代码框架长成这样：

紧张由几个部分组成

1. controller：吸收前端发来的request并组装相应的response返回

2. service：处理详细的业务逻辑

3. repository：数据仓库，处理DB的CRUD操控

4. pojo：大略工具的定义

entity：与数据库表逐一对应dto：与业务数据模型逐一对应，例如view object，form objectenumsresponse：http response的封装

5. common

config：配置类utils：工具类const：常量

以上几个部分的详细名称依据个人习气或者公司规范会有所不同，但大体上都分这几个层级。
个中，有两个点较难把握。

1.1 controller和service怎么分？

如果看demo里的代码，controller彷佛是多余的，只是大略的把前真个login和register要求做了一次转发。
是的，在大略的场景下，完备没有必要照本宣科，把controller与service拆分开来。

但是，如果系统功能进一步迭代，这种分层就有必要了。
我们先认识一下MVC（Model/View/Controller）模型（如下图，图片来源于网络），MVC是一种设计规范或者理念，任何繁芜的业务都可以拆分成三类模块：Model（Service）、View与Controller。

View卖力页面交互；Controller作为掌握层，决定调用哪些做事处理View传来的要求并返回相应的数据；Model，也即Service卖力处理详细的业务逻辑，并调用数据库做持久化处理。

以最大略的login登录场景来举例：

1. View卖力搭建登录页面，组装页面上用户输入的数据传给Controller，并卖力把Controller回传的数据显示在页面上。

2. Controller吸收View传来的login要求，在大略的场景下只需把login要求转发给Model（service）层做处理，并吸收Model的处理结果回传给View显示，就像demo里那样。

但假设，用户交互的不仅仅有网页浏览器，我们还设计了一个移动端APP，同样也有登录要求，这时Controller就派上用场了。
由于屏幕大小的限定，APP登录后页面所展示的用户信息一样平常与网页端有所不同，偷

常日的做法，由后端组装每一个View所需的数据，组成一个VO（View Object）回传给前端。
那么既然网页与APP显示的数据不同，很显然我们须要两个不同的VO，这个事情的调度该当在Controller层面完成。

网页端来的登录要求，Controller首先调用AccountService里的login接口，完成登录的验证并拿到登录后获取的uid以及token；接着调用UserInfoService，获取用户的一些根本信息，比如昵称、头像等；再调用HistoryService获取用户最近浏览的几篇文章信息。
然后把这些数据打包成一个MainPagePcObject回传给网页端，这样用户在登录后的主页上可以看到个人信息以及最近的浏览记录。

APP来的登录要求，，Controller首先调用AccountService里的login接口，完成登录的验证并拿到登录后获取的uid以及token；接着调用UserInfoService，获取用户的一些根本信息，比如昵称、头像等。
然后把这些数据打包成一个MainPageMobileObject回传给APP，这样用户在登录后的主页上可以看到个人信息（由于屏幕大小的限定，APP主页上放不下近期浏览记录，以是Controller并没有调用HistoryService）。

Controller根据不同View的要求，调度不同的Service，组成适当的DTO回传给View显示（以上的代码实现，将在后续讲述前端系统那一篇时加入）。

3. Model（Service）卖力处理详细的业务逻辑，比如AcountService卖力处理账号的注册/登录/登出等操作。
UserInfoService卖力新增/修正/删除用户头像、昵称、爱好等个人信息。

1.2 Pojo里的工具有哪些，如何区分？

Pojo = Plain Ordinary Java Object，也便是大略java工具，意味着只有数据不含任何逻辑操作的工具。
我们可以把response，enums放在里面，还有与库表逐一对应的entity放在里面，接着还有各种眼花缭乱的DTO、VO、FO、DO、PO也可以放在里面。

这些xxO让人不禁遐想起公司里的各种CxO，怎么区分呢？按照个人的理解，画了张图，请看。

层层封装的好处是底层的改动，例如数据库表的变动并不会影响到上层（比如View）的代码。
正所谓脏活累活后端都做了，前端只要卖力美和优雅。

但是分层太多，也会增加代码的繁芜度，以是一样平常的项目里只会做两层数据封装，一层与库表对应的Entity，另一层与业务对应的DTO。

2 微做事初探

良久良久良久以前（实在也就6-7年前吧，但在技能领域可以算良长远了），用java写的后端系统很多都是一套代码集成在一起，有的乃至与前端页面打成一个war包直接支配。

这种办法，运维起来很大略，但是

- 如果业务代码当中一个service出错，可能会导致全体做事不可用

- 各个service的迭代节奏，相互影响

随着互联网业务体量越来越大，以及涉及的业务种类越来越多，这样的技能架构不能跟上业务的发展需求。
回顾文初提过的不雅观点：主要的是按照市场以及用户的需求，在合理的本钱与韶光范围下，搭建出可持续发展的技能系统。
很显然，单体架构无法持续发展下去了，因此微做事架构应运而生。
一种技能，必须有兴旺的业务与用户需求，才可能进入快速发展的通道。

微做事的核心观点便是松耦合，把一个业务中相对独立的部分拆出来做成一个独立的做事系统，可以独立开拓、独立测试、独立支配。
而一套完全的业务系统又由很多个微做事组成。

2.1 Spring & Spring Boot & SpringCloud

Java微做事的框架，一定提到基于Spring体系的Spring Cloud，在此大略阐述一下spring，spring boot，spring cloud的关系。

2.1.1 Spring

更准确的说该当是spring framework，一套基于依赖注入的java开拓框架，spring承担的角色是各个java类之间的依赖关系管理者。

2.1.2 Spring boot

基于spring，供应了面向REST（REpresentational State Transfer）设计风格的框架，通过大略的表明，可以快速搭建起一套web做事。

关于REST风格，推举读一下2000年被首次提出时的论文，传送门如下

英文版

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

中文版

https://www.docin.com/p-525700155.html

2000年我在干嘛？2000年北京的夏天，虽然20年过去了，依然难忘。

2.1.3 Spring Cloud

基于spring boot（依赖注入+面向REST），纳入了许多经由生产验证的开源微做事组件，方便利用者快速的搭建一套微做事框架。
例如netflix的微做事三大件：做事注册与创造Eureka，网关做事zuul，熔断器Hystrix。

2.2 常用微做事组件与架构

技能上很多设计都来源于生活，例如设计模式里的工厂模式、委派模式等。
微做事的组件同样也是来源于我们的日常生活，以是就从生活开始吧。
想象一下我们去一间阛阓买东西的场景，顺着这个场景来先容Spring Cloud中各个关键组件。

做事网关 – Zuul

走进一间阛阓或者一个公共举动步伐，第一道关实在是门卫；而离开一间阛阓，末了一道关也是门卫。
平时我们的出入仿佛感想熏染不到门卫的存在，但当你拿着一把刀试图走进阛阓的时候，门卫一定很快涌现并把你摁倒在地；或者当你离开阛阓时，试图带着并未结账的商品一起离开，门卫也会涌现把你摁倒在地。
同理，在微做事的体系里也有一个门卫起到网关的浸染，Spring Cloud里用的是Zuul（不过已经可以看到spring在推Gateway组件来代替Zuul）。

不论你去阛阓买什么东西、办什么事，都须要通过门卫这一关，同理所有的做事要求都要通过Zuul。
Zuul可以拦截造孽的要求，并对要求做统一的鉴权认证。

Zuul还具备负载均衡的浸染。
Miss1，叨教安歇间往哪走？往前右转50米。
Miss 2，叨教安歇间怎么走？往前右转50米。
Miss 100，叨教安歇间怎么走？往前右转50米。

安歇间保洁员：你md能不能把要安歇的引到别处去，我这里排队都绕两圈了。
Zuul：抱歉，忘却开启负载均衡了，重新来。

Miss 1，叨教安歇间往哪走？往前右转50米。
Miss 2，叨教安歇间怎么走？上2楼左转50米。
Miss 3，叨教安歇间往哪走？往前右转50米。
Miss 4，叨教安歇间怎么走？上2楼左转50米。
这便是负载均衡。
当一个微做事有多台实例时，同一类要求会被均匀分配至不同的实例。

以上负载均衡实现的条件，须要导购妹子Eureka知晓阛阓里有两个安歇间，并且知道它们的详细位置。

做事创造与注册 – Eureka

顺利进入阛阓后，由于弘大的空间，我们并不知道该去哪里买心仪的东西。
于是常日我们都会走到导购台，讯问导购妹子：“叨教，xx成人用品在哪里有售？”导购妹子白你一眼，但依然会尽职的奉告：“请往左走100米进电梯，直达地下18层。
”

在微做事的天下里，同样有一个导购台，spring cloud中用的是Eureka，每一个微做事启动时都要向Eureka报备一下：“报告，我是xx成人用品做事，我的位置在地下18层”。
这样当Zuul收到访问要求后，Eureka可以见告Zuul把要求发往哪里，可能是地下18层，也可能是去晒台。

断路器 – Hystrix

昨天阛阓打了个广告，N95口罩有售，5个只要199，于是本日涌入了大量的人群购买口罩。
相继而来的人流被导购台勾引到了口罩专柜，人群把口罩专柜的售卖妹子围在了中间，在七嘴八舌的讯问声中，售卖妹子崩溃了，无法再回答任何顾客的提问或是售出口罩。

Hystrix登场，它监控到了以上情形，于是在到口罩专柜的路上，竖了一壁告示牌：“N95口罩已售光！
嫡请早！
”于是人群纷纭掉头。

售卖妹子逐渐规复了常态，处理完了一个个围在柜台前的用户需求。
Hystrix于是撤掉了告示牌，有口罩购买需求的客户又连续前往口罩专柜。