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

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

小明虽然从事后端开发工作，但是一直很关注架构这方面的知识，以往都是开发大佬们架构好的应用现在有机会自己去实践下，打算把自己学到的知识应用于实际案例中来。

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

• 合适优于业界领先
• 简单优于复杂
• 演化优于一步到位
  小明作为架构新手，虽然干劲十足，但是也像大部分一样开发人员一样架构经验较少，不知道如何下手去开始架构，万事开头难啊！小明请教了下公司的西踢殴（CTO），给了一句25字的架构真言：架构设计的主要目的是为了解决软件系统复杂度带来的问题
  

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

发现复杂点

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

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

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

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

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

   设计架构方案

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

• 系统复杂性提高
• 运维成本提高
• 系统可用性降低
• …
  小明思考了下简单优于复杂原则，决定使用最简单的本地磁盘存储图像文件，但是使用本地磁盘的方案一定要考虑扩展性，将来随时都可能扩容、迁移数据，于是小明对图像存储做了个简单的抽象层：
  

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

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

• 用户提交图片
• 检测人脸
• 人像与背景切割
• 将切割后的图交给客户处理
• 客户端合成背影、正装生成证件照
  检测人脸、头像分割这类技术公司也没有使用过，基本上自研是不可能的，再说人力成本也不够，首先合适的方案就是用第三方的服务，一番调研发现百度AI有人像处理的能力，小明开始考虑使用百度AI的服务，于是引入百度AI的服务：
  

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

总结

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

推荐阅读：

• ”12306“秒杀系统的设计艺术
• SpringBoot是如何启动的？这篇文章告诉你答案！
• SpringBoot是如何加载配置文件的？
• 饿了么千万级交易系统的重构设计思路
• 支付系统高可用架构设计实战，可用性高达99.999！
• 大型互联网公司分布式ID方案总结

-END-

架构文摘
ArchDigest
架构知识丨大型网站丨大数据丨机器学习

如有收获，点个在看，诚挚感谢图片

来源：oschina

链接：https://my.oschina.net/u/4343937/blog/4795307