系统架构心得

        2021-8-13，截止这一天，已经是10年的老程序员了，可能由于性格强势原因，工作中通常是以leader角色出现，架构也就是再平常不过的事情了，这里总结一下下。

        架构的定义，其实架构不是一件很高大上的事情，他通常叫“架构设计”，架构的实现就是设计。一个平台需要架构、一个系统需要架构、一段代码可能也需要架构。架构是一种思想的体现，24设计模式就是架构的实现方式。so，架构是一种设计思想

        架构不是额定的，主要根据实际情况而定，最合适的才是最好的。最影响架构的有两方面：业务成熟度 和 业务量。以下根据这两方面进行分析：

业务量\成熟度	哺乳期	成长期	稳定期
小	微内核架构	微内核架构	单体架构
中	微服务架构	微服务架构	微服务架构
大	微服务架构	微服务+分层架构	微服务+分层架构

        业务量，指业务上最小的单元逻辑。

        eg. 用户购买一次商品，可以理解为3个业务单元（加入购物车、下单、支付）。那么用户购买一次商品（未涉及发货等）则业务量评估为3，那么预期会调用的服务接口 为6次左右。只要评估下来接口调用次数低于 非并发连续调用，则可以定义为 “业务量小”；达到容器默认参数配置，则为“业务量中”；超过则可以定义为“业务量大”；（如tomcat默认线程数200，已经具备了大部分业务所需的开销）

        成熟度，代表业务的变性

        eg. 银行的业务可变性极低，终究离不开 存、管、贷 3个字，方案也需经过层层审核，那么一开始就是“稳定期”，而且可能会持续很久。娱乐产品可能就完全不同了，今天是线上娱乐、明天结合手机，后天结合电视

        其实实际项目过程中，架构模型之间是相互嵌套的，不会独立存在。如12306入口统一，下面订单系统与抢票系统各负其责，而抢票系统又分多个层、请求处理层、逻辑层、数据层等

        可见系统架构与项目发展息息相关，特别对于小公司而言。技术上的拿来主义非常欠佳，动不动上dubbo，上各种框架，剩下的全是技术债，老板本来就穷，还被技术债拖累。

        不过无论多么负责的业务与场景，基本上就是、微内核、微服务、分层架构 几个之间的应用于组合。微内核应多元化、微服务应多变性、分层应治理。（别的架构可归类其中，如事件驱动，则是分层架构，剥离响应层）

        做个简单总结，如果产品战略模糊，微内核更适合；如果产品策略模糊，微服务是首选；如果产品已经有所成，要开启分层治理了。