单体应用
当应用尚小时，没有什么不好。但一但随着时间的推移逐渐变大，就会变成一个巨大的怪物。开发、部署、启动时间、修正bug重启等等，阻碍了其可持续性开发、部署的问题。而且对于系统资源的占用容量问题、系统高内聚问题让其可靠性很差。
因而衍生出了微服务架构——处理复杂事物。
微服务架构
其思路是将一个巨大的单体应用，分解为小的、互相连接的微型服务，各服务只关注于自己提供的服务，用 服务间通信 的方式来调用其他服务。比如用 REST API、基于消息的通讯、通过 API Gateway 来传递中间消息等等。（API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，可以用 Nginx 方便实现，后续会讲）
微服务架构模式在 AKF 拆分模型中属于 Y 轴。另外的 X 轴是多个应用副本，用负载均衡调度，以提高吞吐能力和可用性；而 Z 轴是将服务分区。
运行时，每一个服务都可以是一个 Docker 容器，为了保证高可用，这些容器一般运行在云虚拟机上。服务实例前是一个 Nginx 负载均衡器，他们负责在各个实例间分发请求，负载均衡器同时也处理其他请求，如缓存、权限控制、API 统计、监控等等。
如果你想尝到微服务架构的好处，每个服务有自己的数据库是必须的，因为它需要这种 松耦合。
表面上看 微服务架构有点像 SOA，但从另一个角度来看，微服务架构不包含 Web 服务规范（Web Services Specifications）和企业级服务总线（Enterprise Service Bus，ESB，参考），而且它内部也避免使用 ESB 类似的功能和 SOA Canonical Schema 的概念。
Web 服务规范？
企业级服务总线？
SOA Canonical Schema？
微服务架构的好处
好处很多，主要特点在于组件的独立，独立开发、独立部署、独立测试、独立资源等等让服务开发、维护都变得简单。
微服务的不足
很重要的一个不足，是由于它是分布式系统，由此带来的复杂性，如何通信、通信速度等是个问题，根据 CAP 理论，你不得不使用最终一致性的解决方案。
另外就是服务间的依赖关系，在单体中只需要改变相关模块的关系就可以实现，但微服务架构就不一样了，你不得不协调它们的依赖关系。
部署也会是一个问题，因为每一个微服务有各自的配置、部署、扩展、监控等等部分，因此你需要为每个微服务应用配置基础服务，此外还需要一个服务发现机制。成功部署一个微服务需要开发者有足够的部署方法，并实现高度自动化。
一种自动化的方法是使用 PaaS 服务，PaaS 提供给开发者一个部署和管理微服务的简单方法，把所有的问题都打包内置解决了。比如配合 Docker 使用 Mesos 或 K8s 等等。
总结
单体应用只适合于比较轻量级的简单应用。
而微服务架构可以用来构建复杂的应用，但引入了它又带来了新的问题需要解决，比如服务发现、服务部署、拆分策略等等。
网友评论