2015第50周一了解微服务架构
58 网站架构演进
网站在不同的阶段遇到的问题不一样，而解决这些问题使用的技术也不一样，流量小的时候，我们主要目的是提高开发效率，在早期要引入 ORM，DAO 这些技术。随着流量变大，使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC 等方式不断提升网站的稳定性。面对更大的流量时，通过垂直拆分、服务化、反向代理、开发框架（站点/服务）等等，不断提升高可用。在面对上亿级的更大流量时，通过中心化、柔性服务、消息总线、自动化（回归，测试，运维，监控）来迎接新的挑战。未来的就是继续实现移动化，大数据实时计算，平台化…
微服务架构
微服务架构（MSA）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。不过从实践上来说，它会引发很多问题。这些服务之间是如何通信的呢？服务之间的延迟是怎样的？如何测试服务呢？如何检测失败并对其作出响应呢？如果存在大量互相依赖的情况该如何管理部署呢？
实际上微服务本身并没有一个严格的定义，不过从很多人的反馈来看，大家都达成了这样一个共识：微服务是一种简单的应用，大概有10到1000行代码。从物理角度来说，这些服务都很小，你可以在同一台机器上运行大量服务，不必担心内存或是资源等问题。重申一遍，基于大型框架的简单库将会取得最后的胜利，你会发现对第三方库的依赖越来越少。
本质上，微服务是自我托管的，他们获取一个端口然后监听。这意味着你将失去典型的企业应用服务器所带来的很多好处，服务需要提供这些必要的功能（性能度量、监控等等）。
你可能会发现在某些情况下，一个完整事务中对JSON负载的序列化与反序列化的代价会造成系统瓶颈。也许JSON并不适合，你可能需要使用别的协议，如Protobuf等。服务之间的某些通信可以是完全解耦的，事实上，有些服务可以随意发布事件或是数据。他们只是将其扔出去（比如说消息总线），也许有一天出现了某个服务，然后开始监听了。此外，也许系统的某些部分会以批量/离线的流程进行运作，他们可能会在几小时后才从队列中取出消息。微服务架构可以实现这种灵活性而无需修改整个架构。
哪个公司或产品使用微服务架构?
大部分大型网站系统如Twitter, Netflix, Amazon 和 eBay都已经从传统整体型架构monolithic architecture迁移到微服务架构
