适用场景：预警，监控，对数据有有效期要求的情况。Lambda架构Lambda架构算是大数据系统里面举足轻重的架构，大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支：实时流和离线。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。流式通道处理为保障实效性更多的以增量计算为主辅助参考，而批处理层则对数据进行全量运算，保障其最终的一致性，因此Lambda最外层有一个实时层和离线层合并的动作，此动作是Lambda里非常重要的一个动作，大概的合并思路如下：适用场景：同时存在实时和离线需求的情况。
Kappa架构Kappa架构在Lambda 的基础上进行了优化，将实时和流部分进行了合并，将数据通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。适用场景：和Lambda类似，改架构是针对Lambda的优化。
Unifield架构Unifield架构更激进，将机器学习和数据处理揉为一体，从核心上来说，Unifield依旧以Lambda为主，不过对其进行了改造，在流处理层新增了机器学习层。可以看到数据在经过数据通道进入数据湖后，新增了模型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含着对模型的持续训练。
适用场景：有着大量数据需要分析，同时对机器学习方便又有着非常大的需求或者有规划。相关：舆情大数据系统架构设计与实现：https://www.toutiao.com/i6537119210336682510/大数据架构的分析应用：https://www.toutiao.com/i6613946595891216910/。
架构师在做一个网站的架构时要做哪些工作（按顺序排列）？
我是一个假的架构师，真的程序员。现在所在的项目，是去年八九月份启动的，虽然不是一个网站，但是大部分工作都是类似的，那么我给大家介绍一下这半年我做了哪些工作。一般新建一个项目有两种背景：一种是没有系统，需要重新建立；一种是有老系统，但是因为种种原因，需要新建一个系统把老系统替换掉（或替换部分功能）；我们算是后者，老系统已经运行多年，主要工作是对外提供接口服务，现在服务的效率和抗压性都无法满足业务需求。
需求梳理需求，在开发之前一定要明确需求。因为是对老系统的改造，所以需求相对来说比较明确。梳理老系统有多少接口，压力比较大的接口有哪些，确定接口迁移的优先级。确定第一批迁移的接口之后，需要对接口的处理逻辑进行梳理，包括出参入参都是什么，对参数有哪些校验，出参的是从什么表的什么字段取得，查询条件是什么，是否对数据进行了加工、转移等处理。
主要是通过“扒代码”的手段，这一步很痛苦（程序员们都懂的）。压力预估因为是老改新，压力容易预估出来，我们主要关注的几个点：现有系统的数据量有多少，年增长的数据量是多少。多少系统在调用，大概服务器的数量是多少。平均每天的调用量，如果业务几种在某些时间段内，比如工作时间，那么就要估计出每小时的量大概是多少。
业务高峰期的时候，量有多少。架构设计其实我也是野路子出身，我在做这一步所做的工作有这些：整理项目的功能点，比如我们这个项目主要功能有：数据抽取、数据存储、数据加工、服务提供；这一步形成整体的功能架构。对每个大的功能点，评估需要使用的资源，拿数据加工为例：数据加工主要就是批处理，需要Tomcat部署Java程序，需要Redis做分布式锁和缓存，需要MongoDB做加工后的数据存储；这一步形成整体的方案规划。
继续详细的评估，根据前期统计的数据量，对MongoDB的部署进行评估：是否需要分片，如果分片的话，前期部署几个分片，容量申请多少；当这些评估都做完之后，就可以把一个一个的点汇总起来，就形成了物理部署架构。到了这一步，基本上技术架构图也就出来了。在设计过程中，还要和很多人进行沟通，比如DBA、比如领导。
开发到了开发阶段，我依然在。这时候，一边招人（招人有些晚了），一边搭框架；一边面试，一边写代码。最后开发人员招的差不多的时候，我从无到有，第一个接口基本上开发完成了...现在嘛，我依然在项目里面，沟通需求、设计、任务分配、写写代码、看看开发人员写的代码再给他们提提意见，如果别的项目组有设计或开发方面的问题，我也会帮忙处处主意；我总觉得我是个假的架构，真的程序员。
一个SAAS系统服务平台（前后端 中台）的最佳开发架构是？
我是全栈工程师。我个人看现在的行情和报价。前端主流是vue.js，react.js都有自己的生态系统和体系，上手很容易。后端推荐Java。大小项目都可以用java，推荐springboot脚手架。可以使用微服务框架springcloud作为框架，可以根据不同的业务划分成单一的服务，独立部署。
