回顾互联网行业的金科玉律：只有变化才是不变的。在设计架构时，一开始就要抱着业务随时可能变动导致架构也要跟着变动的思想准备去设计，差别只在于变化的快慢而已。因此在设计架构时一定是要考虑可扩展性的。
在思考怎样才是可扩展的时候，先想一想平常开发中什么情况下会觉得扩展性不好？大都是因为系统庞大、耦合严重、牵一发而动全身。因此对可扩展架构设计来说，基本的思想就是拆分。
拆分也有多种指导思想，如果面向业务流程来谈拆分，就是分层架构；如果面向系统服务来谈拆分，就是 SOA、微服务架构；如果面向系统功能来拆分，就是微内核架构。
分层架构
分层架构是我们最熟悉的，因为互联网业务下，已经很少有纯单机的服务，因此至少都是 C/S 架构、B/S 架构，也就是至少也分为了客户端/浏览器和后台服务器这两层。如果进一步拆分，就会将后台服务基于职责进行自顶向下的划分，比如分为接入层、应用层、逻辑层、领域层等。
分层的目的当然是为了让各个层次间的服务减少耦合，方便进行各自范畴下的优化，因此需要保证各层级间的差异是足够清晰、边界足够明显的，否则当要增加新功能的时候就会不知道该放到哪一层。各个层只处理本层逻辑，隔离关注点。
额外需注意的是一旦确定了分层，请求就必须层层传递，不能跳层，这是为了避免架构混乱，增加维护和扩展的复杂度，比如为了方便直接跨层从接入层调用领域层查询数据，当需要进行统一的逻辑处理时，就无法切面处理所有请求了。
SOA 架构
SOA 架构更多出现在传统企业中，其主要解决的问题是企业中 IT 建设重复且效率低下，各部门自行接入独立的 IT 系统，彼此之间架构、协议都不同，为了让各个系统的服务能够协调工作，SOA 架构应运而生。
其有三个关键概念：服务、ESB 和松耦合。
服务是指各个业务功能，比如原本各部门原本的系统提供的服务，可大可小。由于各服务之间无法直接通信，因此需要 ESB，即企业服务总线进行对接，它将不同服务连接在一起，屏蔽各个服务的不同接口标准，类似计算机中的总线。松耦合是指各个服务的依赖需要尽量少，否则某个服务升级后整个系统无法使用就麻烦了。
这里也可以看出，ESB 作为总线，为了对接各个服务，要处理各种不同的协议，其协议转换耗费了大量的性能，会成为整个系统的瓶颈。
微服务
微服务是近几年最耳熟能详的架构，其实它和 SOA 有一些相同之处，比如都是将各个服务拆分开来提供能力。但是和 SOA 也有一些本质的区别，微服务是没有 ESB 的，其通信协议是一致的，因此通信管道仅仅做消息的传递，不理解内容和格式，也就没有 ESB 的问题。而且为了快速交付、迭代，其服务的粒度会划分地更细，对自动化部署能力也就要求更高，否则部署成本太大，达不到轻量快速的目的。
当然微服务虽然很火，但也不是解决所有问题的银弹，它也会有一些问题存在。如果服务划分的太细，那么互相之间的依赖关系就会变得特别复杂，服务数量、接口量、部署量过多，团队的效率可能大降，如果没有自动化支撑，交付效率会很低。由于调用链太长（多个服务），因此性能也会下降，问题定位会更困难，如果没有服务治理的能力，管理起来会很混乱，不知道每个服务的情况如何。
因此如何拆分服务就成了每个使用微服务架构的团队的重要考量点。
