这个图本身的内容、关于各个架构的描述、优缺点等等，网上简单搜索一下有大把大把的。软件发展的不同时期、阶段，对技术的理解、选择和应用都有着不一样的诉求。架构的选型，永远只有“合适与不合适”，永远没有“哪个更好”的说法。我们今天来谈论微服务，并不是因为它更牛，而是经过谨慎分析，认为微服务的思想更符合我们的目标。
提到微服务，就没法不提到这位“大神”——马丁·福勒，他没有直接给微服务下一个精准的定义，而是给出了微服务特点的描述。大概从以下四个方面来说：
- 根据业务模块划分服务种类。 “微”思想的体现
- 每个服务可以独立部署并且互相隔离。 「服务」思想的体现
- 通过轻量的 API 调用服务。 微服务中“解耦”思想的体现
- 服务需要保证良好的高可用性。
要做好微服务，就要做好一定的准备工作。
从五个具体的方面来谈：
- 业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。
- 服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、 降级，都要做好相应的技术准备。
- 自动测试，一定要自动化。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈， 为了保证高效的迭代，尽量做到更多的环节实现自动化。
- 自动运维 ：微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今 天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。
- 监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在 实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。
最后，微服务不是银弹，软件领域没有银弹，微服务以其特有的优势在解决一些问题的同时，也引入了其他问题，以下这几点，必须要深刻的思考，三思而后行。
