varyall的专栏

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。根据业务模块划分服务种类。 每个服务可以独立部署并且互相隔离。 通过轻量的 API 调用服务。 服务需要保证良好的高可用性。组件化是指解耦复杂系统时将多个功能模块拆分、重组的过程，有多种属性、状态反映其内

微服务架构优缺点之前转载过一篇对 Martin Fowler 大师写的微服务架构的说明文章：《微服务（Microservices）》。今天再转载一篇对于这个架构的优缺点进行总结的文章。转载自：《微服务，让开发过程更简单还是更复杂？》、《有关微服务架构的争论：更简单还是更复杂？》。  随着DevOps、持续交付等理念的深入人心，微服务架构开始走进我们的

微服务架构采用Scale Cube方法设计应用架构，将应用服务按功能拆分成一组相互协作的服务。每个服务负责一组特定、相关的功能。每个服务可以有自己独立的数据库，从而保证与其他服务解耦。耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。解耦：将存在的依赖去掉，比如类A的一个函数需要类B的一个函数返回值，那么A就是依赖B，那么B改动时A很有可能功能受

why当我们使用一个新技术的时候，应该首先问的一个问题就是why：为什么要使用这个技术？或者问：这个技术是可以解决什么问题。我也想写篇微服务的文章，以及微服务的优缺点在微服务架构中，当一个大型系统被拆分成微服务系统以后，不仅包括功能拆分，还包括系统拆分、代码拆分、数据库拆分、缓存拆分等，多个系统的部署、维护、调用关系、调度、监控、fail over就会成为一系列问题。同时微服务系统划分越