最近无意看到两篇关于软件架构的文章：
大多数人和文章，一提到软件设计就搬出一堆设计模式这种八股文，实在是没办法看下去。这两篇文章中有些原则虽然描述不一样，但意思是一样的。比如API先行，以服务和API的视角来看问题，而不是技术和底层的角度等；选择主流成熟的技术，别重复造轮子，你要选择可享受“前人种树，后人乘凉”的有技术红利的技术等等
但我感受最深的有3条原则：
只有服从了标准，你的架构才有更好的扩展性。这些标准和规范最好是服从业界的标准，而非自己定义的标准，这些标准和规范，包括：服务间调用的协议标准和规范、命名标注和规范、配置规范、日志规范、监控规范、中间件和第三方软件使用规范、版本规范等等。特别是Restful API规范，非常重要，它的最大好处是监视可以很容易地做各种统计分析，控制系统可以很容易的做流量编排和调度，缓存系统也可以非常方便的对接口数据进行缓存。国外有两家公司：Paypal和Microsoft非常重视Restful规范，国内对接过很多大厂的开放平台，没一个重视的。
所谓“呼吸感”就是负载高时可以即时扩展，负载低时可随时减少资源。简单来说，就是软件可伸缩。让做到软件随负载伸缩而又不影响业务，那么就只能是水平伸缩，即通过增加或减少服务节点来弹性调整系统容量，如果你的架构不支持水平扩展，那么就不是合格的架构。
如今，除非特殊原因，应该没有团队和公司会自建物理的基础设施或是数据中心。成熟的云厂商在安全性、可用性方面有更多的经验，其基础设施本身也就有更高的可靠性，因此，除非特殊原因，你的架构应该全面上云。云原生的话题太大，以后想到啥再说。这里需要着重关注后半句，即不要与特定的云厂商绑定太紧，一条简单的原则是：尽量不要使用云厂商特有的服务。比如容器、数据库、中间件、存储、安全等，大部分云厂商的服务都类似，可以放心使用；而有些专有的服务，比如最近调研的阿里云分布式调度系统SchedulerX，如果后面因为某些原因需要更换云厂商，那么相关的架构和代码都需要重构，成本太高。