3.常见的系统级框架
前言
提到架构就不得不提框架。
架构我们上一节讲到，是指系统的结构，那么对于某种结构，我们需要按照其结构完成对应的功能和开发。
那么有没有能帮助填充好，或者已完成部分工作的呢？
有的，那就是框架。
就像我们写ppt或者word，比较好的结构是有封面，有目录页，有页眉/页脚，有结尾等，如果我们自己做，就需要从头开始，每个地方都要做一些。
但是可以用一些别人做好的，或者自己上次使用过的文档，那么直接改成自己想要的内容就可以了，工作量立省一大半。
所以你也可以理解框架是一种模板。
常见的框架
web系统框架
在目前的web系统体系中，比较流行的是单体项目架构、前后端分离项目架构、微服务项目架构。
前后端不分离
前后端不分离，都在一个程序包中，也就是一套系统里可以实现从数据库读取到页面呈现的所有功能。
典型的就是php的thinkphp和Larave，用户看到的页面其实都是php文件，php文件通过调用相关服务呈现出了html文件的燕子。
这种架构是之前颇为流行，现在也有一些场景还在使用。
前后端分离项目架构
项目分为两个系统，两个项目独自开发，独立部署，通过接口的进行数据通信。
前端系统负责界面现实，显示内容。 后端系统是指程序或者服务，负责逻辑、数据计算。
例如查看用户余额的时候，前端系统向后端系统请求余额数据，后端系统返回对应的数据，例如： 
而前端系统根据获得的数据进行显示。 
前端常见的web框架有
- vue
- react
- angular
前端常见的APP/HTML5框架
- uniapp： 跨平台，一套代码，多端发布
- flutter： 跨平台，一套代码，多端发布
- react-native： 跨平台，一套代码，多端发布
- weex： 跨平台，一套代码，多端发布
- taro： 跨平台，一套代码，多端发布
- 终端原生： 使用每种终端的sdk 研发。
前端的发展比较快，随时都会有新的框架出现。
后端框架：
- java：sprintboot
- c#/net：.net webapi
- go： gin
微服务架构
微服务是指将后端服务拆分成了1+多模式，或者多+多模式。 以1+多模式，相当于使用服务的时候，都去找一个领头的人，然后他会分配一个具体干活的人来负责。 实现的过程简单来说就是： 第一，所有干活的人都要先去领头哪里报道，这一部分称为服务发现。 这个负责领导的人，我们称之为服务网关。
第二，当有请求时，由领头的根据规则和类型分配给具体某个干活的服务。
第三，领头的会时不时询问干活的人，还能不能继续接受新任务，以及还在不在，不如服务的离线。
微服务架构主要讨论实现微服务的体系，不讨论所对应的后端框架。
- java： Springcloud、Dubbo
- .net： Consul 、Service Fabric（托管）
- go： go-zero、gRPC
- rpc框架： ZeroC-Ice、Thrift、Tars
客户端框架
是指做独立客户端应用的框架，例如常用的QQ就是一个客户端，客户端跟操作系统关系比较大，当然也有一些号称跨平台的方案，但是并不是太好。 毕竟选择用客户端就说明有性能、本地存储之类的需求，如果最后开发完之后实现不了这些还不如用web端解决方案。
选择框架
框架的选择是由技术团队来选择，产品人员一般了解即可，但是在技术选型的过程中，产品人员需要提供功能范围和需求供技术人员参考。
因为框架的好坏难以一言盖之，产品使用什么框架也需要根据自身的情况来考虑， 例如团队实力、交付周期、客户要求、功能特点。
具体来说就是如果是简单的功能，并且交付周期比较短，就选择较为容易上手的框架。 如果是复杂的功能，或者交付时间比较长，那么可以考虑更成熟或者性能更好的框架，甚至自己打造一个框架。
例如要做一款客户端，需要涉及到很多硬件设备的调用，那么需要提前告知开发人员，否则选择一些混合模式的框架可能就无法调用或者调用很困难。
这是框架的问题，改不了
不得不说，这可能是产品人员在提需求的时候，经常被拒绝的理由之一。那么到底是是不是框架的问题呢？ 实际上情况会分几种： 1、框架没问题，但是使用的方式有问题 框架本身没有问题，但是使用方式错了，导致框架报错了，所以技术人员说是框架的问题。
2、对框架不熟，导致某些功能不了解不会用。 框架一般包含很多的功能，如果只用一些表面的功能而不深入研究，对于某些功能点是不太了解，好比大多数人都只用excel做做表单，但是对于公式、数据透视表之类的基本都不太了解，然后就反馈说excel做不了。
3、框架确实做不了，绕过方式又太麻烦。 框架虽然做不了，不过框架作者提供了扩展方案，然而技术团队不想学习或者觉得扩展的技术门槛太高、太耗人工之类的原因，不愿意做。
4、确实做不了。 真的做不了，如果想实现对应的功能，唯有换框架。
对于以上几种情况，实际上前三种的比较多，尤其是第二种， 一般是技术团队的任务比较重，又不给技术人员了解学习的时间，所以才会产生一开始的问题，碰到问题就说是框架的问题。
具体是那种问题，其实应该由技术总监或者技术经理来判断，产品人员需要提供的就是该需求的重要程度以及优先级。如果是可有可无的需求或者优先级没那么高，那么就需要放一放了。
而如果是重要的需求，即使是难度很大，也是需要技术团队去攻克。
总结 以上是简单一些跟架构相关的系统级别框架，还有其他更底层或者更技术的框架作为整体系统的补充，就不在此讲解。