过度的抽象，过度的开放性，往往让接触他的人无所适从。讲到这里你可能以为我要开始讲过度设计这个主题了，但其实不然，我只是想以这个话题作为引子，和大家讨论一下关于设计一个插件架构我是如何思考的。

1）高可用性：自动化运维，整体可用性达到4个9，全年不可用时间累积不超过50分钟，单个系统可用性达到5个9，全年不可用性累计不超过5分钟。 2）高扩展性：系统架构简单清晰，系统间低耦合，扩展便捷，业务功能增删改便捷。 3）低成本：增加服务的可重用性，提高开放效率，降低软硬件成本…

没多少人能记住上面的定义，需要注意的是本文不是专业讨论系统架构的文章，笔者也还没到那个水平. 所以暂时没必要纠结于什么是架构模式、什么是架构风格。在这里尚且把它们都当成一个系统架构上的套路, 所谓的套路就是一些通用的、可复用的，用于应对某类问题的方式方法. 可以理解为类似“设计…

0. 可视化搭建的使用链路 Low-code: 如果面向的是研发，场景是中后台或者 toB 的一些业务，我们需要搭建的就是低代码生产链路，用户只需要改动少量的代码就能完成一个应用或者页面的全链路流程。 No-code: 如果面向的是非研发（如产品经理、设计师），场景大多数都是一…

电子相册，一个可以可视化编辑的H5网页，用户只需要选择相应的模板进行组合，替换页面里的素材就能制作出一套可以媲美专业人员进行开发的H5宣传页。 使用者是没有任何开发经验的用户，这种情况对系统的可用性和拓展性的要求非常的高，因为每个人的想法是不一样的，这样就导致系统对接的需求是多…

这是一次源于头条 Android 客户端软件架构问题的探讨，之所以冠上“嘴炮”之名，是因为它有一些务虚；同时又夹杂了一些方法论，不仅适用于客户端软件架构，也适用于其他工作场景，希望对大家有所帮助。