系统进化理论概述
在系统架构与设计的实践中，经历了两个阶段，一个阶段是早些年常见的集中式系统，一个阶段是近年来流行的分布式系统;
集中式系统
集中式系统也叫单体应用，就是把所有的程序、功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务;
分布式系统
分布式系统就是把所有的程序、功能拆分成不同的子系统，部署在多台不同的服务器上，这些子系统相互协作共同对外提供服务，而对用户而言他并不知道后台是多个子系统和多台服务器在提供服务，在使用上和集中式系统一样;
集中式系统跟分布式系统是相反的两个概念，他们的区别体现在“合”与“分”。
系统进化理论背景
系统进化的背景与中国互联网用户规模庞大有巨大关系，中国互联网用户规模有7.7亿，庞大的用户访问量对系统的架构设计是巨大的挑战;
产品或者网站初期，通常功能较少，用户量也不多，所以一般按照单体应用进行设计和开发，按照经典的MVC三层架构设计;
随着业务的发展，应用功能的增加，访问用户的增多，传统的采用集中式系统进行开发的方式就不再适用了，因为在这种情况下，集中式系统就会逐步变得非常庞大，很多人维护这么一个系统，开发、测试、上线都会造成很大问题，比如代码冲突，代码重复，逻辑错综混乱，代码逻辑复杂度增加，响应新需求的速度降低，隐藏的风险增大;
所以需要按照业务维度进行应用拆分，采用分布式开发，每个应用专职于做某一些方面的事情，比如将一个集中式系统拆分为用户服务、订单服务、产品服务、交易服务等，各个应用服务之间通过相互调用完成某一项业务功能。
微服务架构的优缺点
1、我们知道微服务架构是将系统中的不同功能模块拆分成多个不同的服务，这些服务进行独立地开发和部署，每个服务都运行在自己的进程内，这样每个服务的更新都不会影响其他服务的运行;
2、由于每个服务是独立部署的，所以我们可以更准确地监控每个服务的资源消耗情况，进行性能容量的评估，通过压力测试，也很容易发现各个服务间的性能瓶颈所在;
3、由于每个服务都是独立开发，项目的开发也比较方便，减少代码的冲突、代码的重复，逻辑处理流程也更加清晰，让后续的维护与扩展更加容易;
4、微服务可以使用不同的编程语言进行开发;
但是在系统架构领域关于微服务架构也有一些争论，有人倾向于在系统设计与开发中采用微服务架构实现软件系统的低耦合，被认为是系统架构的未来方向，Martin Fowler(马丁.福勒)也给微服务架构很高的评价;
同时，对微服务架构也有人持反对观点，他们表示：
1、微服务架构增加了系统维护、部署的难度，导致一些功能模块或代码无法复用;
2、随着系统规模的日渐增长，微服务在一定程度上也会导致系统变得越来越复杂，增加了集成测试的复杂度;
3、随着微服务的增多，数据的一致性问题，服务之间的通信成本等都凸显了出来;
所以在系统架构时也要提醒自己：不要为了微服务而微服务。
在系统架构与设计的实践中，经历了两个阶段，一个阶段是早些年常见的集中式系统，一个阶段是近年来流行的分布式系统;
集中式系统
集中式系统也叫单体应用，就是把所有的程序、功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务;
分布式系统
分布式系统就是把所有的程序、功能拆分成不同的子系统，部署在多台不同的服务器上，这些子系统相互协作共同对外提供服务，而对用户而言他并不知道后台是多个子系统和多台服务器在提供服务，在使用上和集中式系统一样;
集中式系统跟分布式系统是相反的两个概念，他们的区别体现在“合”与“分”。
系统进化理论背景
系统进化的背景与中国互联网用户规模庞大有巨大关系，中国互联网用户规模有7.7亿，庞大的用户访问量对系统的架构设计是巨大的挑战;
产品或者网站初期，通常功能较少，用户量也不多，所以一般按照单体应用进行设计和开发，按照经典的MVC三层架构设计;
随着业务的发展，应用功能的增加，访问用户的增多，传统的采用集中式系统进行开发的方式就不再适用了，因为在这种情况下，集中式系统就会逐步变得非常庞大，很多人维护这么一个系统，开发、测试、上线都会造成很大问题，比如代码冲突，代码重复，逻辑错综混乱，代码逻辑复杂度增加，响应新需求的速度降低，隐藏的风险增大;
所以需要按照业务维度进行应用拆分，采用分布式开发，每个应用专职于做某一些方面的事情，比如将一个集中式系统拆分为用户服务、订单服务、产品服务、交易服务等，各个应用服务之间通过相互调用完成某一项业务功能。
微服务架构的优缺点
1、我们知道微服务架构是将系统中的不同功能模块拆分成多个不同的服务，这些服务进行独立地开发和部署，每个服务都运行在自己的进程内，这样每个服务的更新都不会影响其他服务的运行;
2、由于每个服务是独立部署的，所以我们可以更准确地监控每个服务的资源消耗情况，进行性能容量的评估，通过压力测试，也很容易发现各个服务间的性能瓶颈所在;
3、由于每个服务都是独立开发，项目的开发也比较方便，减少代码的冲突、代码的重复，逻辑处理流程也更加清晰，让后续的维护与扩展更加容易;
4、微服务可以使用不同的编程语言进行开发;
但是在系统架构领域关于微服务架构也有一些争论，有人倾向于在系统设计与开发中采用微服务架构实现软件系统的低耦合，被认为是系统架构的未来方向，Martin Fowler(马丁.福勒)也给微服务架构很高的评价;
同时，对微服务架构也有人持反对观点，他们表示：
1、微服务架构增加了系统维护、部署的难度，导致一些功能模块或代码无法复用;
2、随着系统规模的日渐增长，微服务在一定程度上也会导致系统变得越来越复杂，增加了集成测试的复杂度;
3、随着微服务的增多，数据的一致性问题，服务之间的通信成本等都凸显了出来;
所以在系统架构时也要提醒自己：不要为了微服务而微服务。
