技术架构涵盖内容和演变过程

• 用场景：你的应用场景是最先决定你采用哪种架构的，这可能会包括：电商、交易、社交、视频、音乐、出行、外卖等等，当然除了互联网中的应用场景，还会有一些基于物联网的应用，例如：PLC 应用、IO 板卡、中继器打码以及你熟悉的小区自提柜。
• 业务规模：这决定了你的用户范围和体量，如果你是在当下正火的抖音里开发商城，那你的用户体量基数从上线之初就会特别大，但如果你还是一个初创团队小电商，那么每天的QPS维持在 5~10，可能这个阶段你就不需要有能承载多大体量的系统架构。这也类似网络上的笑话，团队初期招聘某大厂大佬，上来就是超级架构的建设，没等系统开发完呢，公司没了!
• 服务类型：有了场景和规模的设定，接下来要考虑的内容就是整个技术实现层面的内容，服务类型可能是整个团队最初对系统拆分模块和如何支持的考量，有了业务的分层就可以划分出由各个团队来协同支持开发。当然如果是小团队那么这一环节最好缩小，哪怕把所有的功能都开发到一个系统里去，先快速验证市场是主要的。
• 部署结构：是部署结构决定了开发模式，单体部署、集群部署、分布式部署、云环境等，这些都会决定技术的选型和框架的结构。例如不引用RPC，那么就很难实现分布式部署，如果不使用分库分表和大数据环境，也很难支撑起分布式部署下的数据应用。
• 开发框架：MVC、DDD，这应该是研发人员最先接触到整个系统架构中的代码开发部分，也就是具体功能的具体实现层，如果是单体应用那么基本一个 MVC 结构就够了，但如果是大体量的分布式部署，那么你的系统开发里可能有的是操作数据库的，有的是专门做业务的，有的是用于支持分布式任务和消费MQ消息的。
• 技术选型：其实开发框架，无论是 MVC 还是 DDD，都是不影响技术选型的，任何一种语言都可以放在同样的架构框架中进行开发，比如你说 Java、PHP、GO，只不过它们都是在自己语言下有自己的解决方案。

综上，就是我们研发人员在做架构设计时要考虑的核心内容，随着我们技术的不断迭代也会有更多更新的思想，就像20年热起来中台、21年热起来的低代码，都是为了更好的让架构降本增效的实施方案。

但如果想了解和学习架构，最好还是要从它是一颗小树苗时候看起，看看它是如何一点点长大的。在头脑中有了一个这样的架构体系，也能让大家更好的理

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!