再小的应用也有架构，面向架构新手的架构实践！

文章主人公：小明，就任于某互联网公司，从过后端开发工做。最近小明收到通知公司须要开发一款《证件照》应用，须要征集架构方案，主要功能包括：

小明虽然从过后端开发工做，可是一直很关注架构这方面的知识，以往都是开发大佬们架构好的应用如今有机会本身去实践下，打算把本身学到的知识应用于实际案例中来。

小明的脑海里是回想了下架构的基本三原则：

• 合适优于业界领先
• 简单优于复杂
• 演化优于一步到位

小明做为架构新手，虽然干劲十足，可是也像大部分同样开发人员同样架构经验较少，不知道如何下手去开始架构，万事开头难啊！小明请教了下公司的西踢殴（CTO），给了一句25字的架构真言：架构设计的主要目的是为了解决软件系统复杂度带来的问题

小明也算骨骼惊奇，久经沙场（996没少锻炼人~~），思考了“架构真言”既然是为了解决软件系统繁杂度的问题，那不得先找出系统的复杂点在哪里吗？

发现复杂点

小明根据“架构真言”开始思考《证件照》应用的复杂点，首先它是一款工具类应用，主要功能是进行图像处理：

小明发现图像处理和图像存储可能比较复杂，公司现阶段没有专门作图像处理团队，也没有大数据团队，这两个问题是要优先解决的问题。

小明如今使用的手机是Galaxy s9一张照片大概是6m，若是初期应用日活1w，假设有20%的人会处理图片，那一天的存储量大约10g，运行一个月就须要300g的存储空间，这个配置个几T的磁盘能够跑个1年左右。不过这只是1w日活还要考虑到十万、百万级别的时候怎么办。

通过讨论小明列出了一些复杂的地方并按优先级作了排序：

1. 图像存储
2. 图像处理
3. 订单处理
4. 物流处理

设计架构方案

对于图像存储复杂性，小明第一个想到的是一个分布式文件存储方案，这样数据容量、可用性均可以获得很好的保障。他首先将这个想法和西踢殴交流了下，西踢殴也没有否定这个方案只是让小明考虑下成本方面的因素，小明回头一想确认引入"分布式文件存储"首先会带来如下几点问题：

• 系统复杂性提升
• 运维成本提升
• 系统可用性下降
• ...

小明思考了下简单优于复杂原则，决定使用最简单的本地磁盘存储图像文件，可是使用本地磁盘的方案必定要考虑扩展性，未来随时均可能扩容、迁移数据，因而小明对图像存储作了个简单的抽象层：

小明对于存储复杂性应用了架构原则中的原则简单优于复杂、演化优于一步到位，同时对于存储的可变性，经过引入抽像层可以有效合理的应对将来的变化。

初步定下来图像存储后，小明开始对图像处理复杂性的问题进行设计，一张证件照的制做流程大体以下：

• 用户提交图片
• 检测人脸
• 人像与背景切割
• 将切割后的图交给客户处理
• 客户端合成背影、正装生成证件照

检测人脸、头像分割这类技术公司也没有使用过，基本上自研是不可能的，再说人力成本也不够，首先合适的方案就是用第三方的服务，一番调研发现百度AI有人像处理的能力，小明开始考虑使用百度AI的服务，因而引入百度AI的服务：

对于图像处理小明考虑合适优于业界领先原则，考虑人力、物力的成本选择合适的方案，而不是一开始就说要自研一套图像处理系统，投入大量的时间和人力去作最后得不偿失。通过一番操做，小明最后整理出一张基础架构图交给了西踢殴，等待西踢殴的转身~~

总结

根据架构设计的主要目的是为了解决软件系统复杂度带来的问题的综指，小明首先找出系统的复杂点，而后通过优先级排序，一步步的解决复杂性的问题，最后结合实际状况设计出一套可行的架构方案。架构设计也是有套路可寻的，虽然案例架构比较简单没有大规模的分布式、高可用、高并发场景，再小的应用也是有架构，也要通过深思熟虑再去实行否则会是满地的技术债，后期要花更多的成本去维护重构。

《架构文摘》天天一篇架构领域重磅好文，涉及一线互联网公司应用架构（高可用、高性 能、高稳定）、大数据、机器学习等各个热门领域。