初识微服务架构

        微服务架构说白了就是一种系统架构上的设计风格，它的主要特点就是将本来独立的系统、大而全的系统拆分红若干个小型服务，这些小服务都是一个独立的进程在运行，并且服务之间能够经过HTTP接口互相调用以保障业务的完整性。拆分红若干小型服务后，每一个服务均可以单独管理了，这样上线后有个别服务有bug或需求变动时，只须要动须要变更的服务便可，避免了独立系统 牵一发而动全身的状况。并且服务独立部署、独立管理，有服务负载增长时，扩展该服务的节点便可，并且扩展是动态、无感知的。

        那么首先要考虑的问题就是怎么拆分原来的系统？有什么拆分原则吗？

        1. 业务因素：拆分服务时首先考虑业务的独立性和专业性，也就是面向业务的，按照业务功能合理的规划每一个服务的边界。每一个服务都是一个独立独立服务内部的要知足高内聚的特色，就是说每一个服务内部的依赖性要高，而服务之间要知足低耦合的原则。好比电商系统中的订单服务、库存服务、购物车服务等。

        2. 架构组织独立性：服务拆分后，每一个服务最好是独立的团队来进行维护，不容许出现团队之间交叉维护的状况。每一个服务都维护着本身的数据存储、业务开发、自动化测试案例以及独立的部署机制。

        3. 投入产出：服务拆分后的运营成本不能高于拆分前的成本。

        运营成本我这里想到两方面，一是服务器、网络等硬件成本，二是运维成本。

        硬件成本：独立系统时期，咱们扩展服务性能的方式一般是提升服务器性能、作集群；而到了微服务时代，每一个服务都是独立部署，这样就能够根据每一个服务的负载程度不一样，单独扩展负载高的服务便可，没必要浪费多余的服务器资源了。

        再说运维成本，无需置疑，服务多了，管理的服务器多了，运维工做量确定比原来高了，但成本必定上升了吗 ？这个能够说上升有限或跟原来差很少，缘由就是自动化运维技术的出现。像jenkins这类自动化工具的出现，以及配合spring boot工程的构建方式，配合以maven、git等工具，使得服务只须要一键部署。

        好了，再把话题拉回来。继续介绍分布式架构，开始提了分布式的一些好处后，咱们再来讲说使用分布式的缺点都有哪些。

•  管理成本的增长。服务拆分的多了，开发团队也就多了，团队多了管理成本必然增长了。
• 运维的新挑战：虽说自动化运维技术的出现帮忙解决了很多运维的工做，可是一旦服务除了问题，解决起来多是多个团队之间的协做，增长了问题解决的复杂性。
• 接口的一致性。接口是服务对外提供的访问入口，以实现业务逻辑。可是当业务变动或其余状况致使的接口变动，须要调用方也要根据变动来配合接口的变动和部署。咱们须要更完善的接口和版本管理，或者严格遵照开闭原则（开闭原则就是说接口的设计，只有接口有bug时才能修改，若是有新特性、功能则须要新的接口来实现）。
• 分布式的复杂性。拆分后的服务是独立进行运行的，服务之间的通讯时网络延迟、分布式事务、异步消息等问题接踵而来。分布式事务如今能够说是一个世界性难题，CAP定理中能够窥的分布式的复杂度远比独立服务的事务来的复杂。关于分布式事务，后续会有讨论。

        总结本章的内容，咱们开始说道系统架构从独立服务发展到了微服务时代，分布式的架构为软件带来了不少好处，如服务的拆分、独立部署、独立管理、节点动态扩展等好处。而后对于如何拆分服务，给出了一些拆分原则。最后，把分布式架构带来的挑战和问题作了说明，这些也是咱们从此使用分布式架构时须要注意的地方。