相信很多人跟我一样，无论身处何地，在系统开发过程中大多数人会问你采用什么架构？基于目前的开发趋势，微服务架构已经越来越被众多的行业内外人知晓。微服务就是把业务场景服务化，在开发过程中以模块化或者项目化的结构，其好处是在更新和新增功能时无需全项目更新，只需更新单一项目。如果结合更高级的策略，使其更专注于业务场景而不是技术！
在此再提一下常见的几个名词：SasS、PasS、IaaS，这三个都是基于云计算的服务。简单来说这三个都是（xx as a Service）,均为基于服务的互联网服务。
Saas（即Software-as-a-Service的缩写），软件即服务软件。是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。普通用户接触到的互联网服务，几乎都是SaaS。软件提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务。举例说明：企业无需购买软硬件，即可通过互联网使用OA系统、crm客户管理系统、ERP系统等管理软件
Paas（即Platform as a Service的缩写），平台服务。指把服务器平台作为一种服务提供的商业模式，通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。
Iaas（即Infrastructure as a Service 的缩写），基础设施即服务。指把IT基础设施作为一种服务通过网络对外提供，并根据用户对资源的实际使用量或占用量进行计费的一种服务模式。（如阿里云的流量、OSS等）
在这种服务模型中，普通用户不用自己构建一个数据中心等硬件设施，而是通过租用的方式，利用 Internet从IaaS服务提供商获得计算机基础设施服务，包括服务器、存储和网络等服务。
是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。
那么问题来了，我们开发系统的时候做的架构会有哪些呢？别跟我说你用spring cloud 云服务等，那些只能忽悠外行，在专业的人眼里只能叫技术栈。废话不多说，上图
这张图简单的把我们常用的一些架构展现出来了。有人就要问了，高并发大流量这个架构能解决不？流量多大才算大？对于日活月活不超过百万的小型平台来说，什么并发和流量出现瓶颈只是在运维和部署的时候未做好应急准备而已，一味的追求高并发的流量，只能给企业带来较大的内耗。各位企业主且行且珍惜！
简单的解析一下这张图：
运维包含了代码管控（git）、私有服务器、Jenkins（自动化发布部署）和容器部署。
开发部分既然是基于微服务框架开发的，那么对于注册中心\配置中心，相比Eureka，个人觉得Alibaba的Nacos比较适合国内的开发。监控部分视系统复杂程度选择开源组件即可。数据库和缓存也可以选择基于云服务的一些服务商即可，对于中小型企业并无必要一定要自己建设机房做什么数据同步。最近看了一些企业招聘提到ELK，其实这个东西的应用不常见，能用到这个的，企业必须要有一个专业的运维团队来关注系统运行状态。那么基于以上，我们的开发者就只需要关注的是自己的业务模块即可。
任何时候任何系统前端就是一个IO组件，关注的就是UE（用户体验）和UI（操作界面），与后端的交互通过负载均衡服务器和网关即可。
(系统完整架构及工作流，仅供参考）
以上只是我个人的经验之谈，欢迎各位留言探讨和指正！
