微服务架构说白了就是一种系统架构上的设计风格，它的主要特色就是将原本独立的系统、大而全的系统拆分成若干个小型服务，这些小服务都是一个独立的进程在运行，而且服务之间可以通过HTTP接口互相调用以保障业务的完整性。拆分成若干小型服务后，每个服务都可以单独管理了，这样上线后有个别服务有bug或需求变更时，只需要动需要变动的服务即可，避免了独立系统 牵一发而动全身的情况。而且服务独立部署、独立管理，有服务负载增加时，扩展该服务的节点即可，而且扩展是动态、无感知的。
那么首先要考虑的问题就是怎么拆分原来的系统？有什么拆分原则吗？
1. 业务因素：拆分服务时首先考虑业务的独立性和专业性，也就是面向业务的，按照业务功能合理的规划每个服务的边界。每个服务都是一个独立独立服务内部的要满足高内聚的特点，就是说每个服务内部的依赖性要高，而服务之间要满足低耦合的原则。比如电商系统中的订单服务、库存服务、购物车服务等。
2. 架构组织独立性：服务拆分后，每个服务最好是独立的团队来进行维护，不允许出现团队之间交叉维护的情况。每个服务都维护着自己的数据存储、业务开发、自动化测试案例以及独立的部署机制。
3. 投入产出：服务拆分后的运营成本不能高于拆分前的成本。
运营成本我这里想到两方面，一是服务器、网络等硬件成本，二是运维成本。
硬件成本：独立系统时期，我们扩展服务性能的方式通常是提高服务器性能、做集群；而到了微服务时代，每个服务都是独立部署，这样就可以根据每个服务的负载程度不同，单独扩展负载高的服务即可，不必浪费多余的服务器资源了。
再说运维成本，无需置疑，服务多了，管理的服务器多了，运维工作量肯定比原来高了，但成本一定上升了吗 ？这个可以说上升有限或跟原来差不多，原因就是自动化运维技术的出现。像jenkins这类自动化工具的出现，以及配合spring boot工程的构建方式，配合以maven、git等工具，使得服务只需要一键部署。
好了，再把话题拉回来。继续介绍分布式架构，开始提了分布式的一些好处后，我们再来说说使用分布式的缺点都有哪些。
- 管理成本的增加。服务拆分的多了，开发团队也就多了，团队多了管理成本必然增加了。
- 运维的新挑战：虽然说自动化运维技术的出现帮忙解决了不少运维的工作，但是一旦服务除了问题，解决起来可能是多个团队之间的协作，增加了问题解决的复杂性。
- 接口的一致性。接口是服务对外提供的访问入口，以实现业务逻辑。但是当业务变更或其他情况导致的接口变更，需要调用方也要根据变更来配合接口的变更和部署。我们需要更完善的接口和版本管理，或者严格遵守开闭原则（开闭原则就是说接口的设计，只有接口有bug时才能修改，如果有新特性、功能则需要新的接口来实现）。
- 分布式的复杂性。拆分后的服务是独立进行运行的，服务之间的通信时网络延迟、分布式事务、异步消息等问题接踵而来。分布式事务现在可以说是一个世界性难题，CAP定理中可以窥的分布式的复杂度远比独立服务的事务来的复杂。关于分布式事务，后续会有讨论。
总结本章的内容，我们开始说道系统架构从独立服务发展到了微服务时代，分布式的架构为软件带来了很多好处，如服务的拆分、独立部署、独立管理、节点动态扩展等好处。然后对于如何拆分服务，给出了一些拆分原则。最后，把分布式架构带来的挑战和问题做了说明，这些也是我们今后使用分布式架构时需要注意的地方。
