应用框架演进
- MVC (Modle View Controller) 架构： 当业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的 MVC 架构是关键。
- RPC (Remote Procedure Call)架构：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的 RPC 框架是关键。
- SOA (Service Oriented Architecture)架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的 SOA 服务治理是关键。
- 微服务架构：随着敏捷开发、持续支付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器 (LXC) 部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期将缩短，运营成本也将大幅下降。
分布式服务框架入门
技术是为商业目标服务的，业务发展到什么规模，就有什么样的技术与之匹配。所以，分布式服务框架实际并没有标准，不同的业务场景会有不同的特性需求。
尽管行业、业务规模不同会导致架构存在一-定差异，但是差异是相对的，共性是绝对的。通过对阿里的Dubbo、淘宝的HSF和亚马逊的Coral Service 进行分析，我们惊讶地发现三者存在很多共性，例如配置化发布服务、基于服务注册中心的订阅发布机制、内部私有二进制协议通信、灵活的路由策略、服务治理等。正因为如此，设计与开发通用的分布式服务框架是完全可行的。
通信框架
绝大多数的分布式服务框架(RPC框架)都推荐使用长连接进行内部通信。
如果我们要构建高性能、低时延、支持大并发的应用系统，使用同步阻塞I/O模型是无法满足性能线性增长和可靠性的，应使用更高效的NIO非阻塞I/O。
除了基础功能，通信框架的可靠性和性能也是非常重要的指标。高性能通信框架的构建成功，为分布式服务框架后续的设计打下了坚实的基础，也为上层的应用层协议栈开发提供了良好的基础设施。