上一篇总结：互联网架构为什么要面向服务？1、为什么要上网架构会出现以下问题：（1）代码到处复制（2）底层复杂度蔓延（3）基础库（so/jar/dll）耦合（4）SQL质量得不到保证，业务相互影响(5)数据库耦合“面向服务”很好地解决了上述痛点。很多评论也提出了很多建设性的意见，总结出来分享给大家：@田卫学习提到：服后可能会导致分布式事务的问题。“没有人愿意引入分布式事务，当基于业务层面进行拆分时，需要业务专家介入，合理拆分服务，未来服务内聚性高，事务性有保障。自夸服务调用，通过补偿等方式，只要最终一致性就够了，毕竟现在银行转账也不是强一致性。”正如@田威所说，分布式事务是业界一直没有完全解决的难题，任何架构设计都是一种妥协，吞吐量？延迟？一致性？哪个是主要矛盾，应该先解决哪个问题。当大数据，高并发、业务复杂是主要矛盾，或许“最终一致性”是“事务”更好的替代方案，或者是业务可以接受的解决方案。同学@侯迪燕提到：多了一层服务层，架构其实更复杂，需要引入一系列机制来管理服务。在RPC服务中，需要注意：（1）RPC服务超时，服务调用者应该有一些应对策略，比如重发（2）支付等关键服务，注意幂等性，因为重发会导致重复操作（3）多服务要考虑并发操作，相当单服务的锁机制比如JAVAsynchronized@黄明学习提到：服务化后，随着规模扩大，必须考虑“服务治理”，否则相互之间的依赖关系服务会变得凌乱。2、互联网微服务架构更“微”适合所有人人们也认识到，随着数据量、流量和业务复杂度的增加，面向服务的架构是架构演进的必经之路。今天要讨论的话题是：微服务架构到底有多“微”才合适？【粗粒度：一个服务层】最粗的玩法，所有的基础数据访问都是通过一个服务来访问的，在业务不是特别复杂的时候还好，但是一旦业务变得复杂，服务层就会变得很重并成为耦合点之一。以微信场景为例，假设有一个通用的服务层来访问基础数据，这个服务层可能是这样的：有一个统一的服务层，用户信息、好友信息、群组信息、消息信息都通过通过这个服务层来来去去。详情：微信一对一消息是写多读少的业务，所以没有缓存。【一个子业务，一个服务】如果所有的信息都存储在一个服务中，那么一个地方的bug就会影响到整个业务，所以在服务层进行细分是比较合理的。如何细分架构？垂直拆分划分是一个很好的方案，把子服务一个一个拆分出来，那么微信的服务架构可能会变成这样：（1）用户相关的子服务就是user-service（2）好友相关的子服务services有friend-serviceservice(3)group相关的子服务有group-service(4)message相关的子服务有msg-service。在这种情况下，如果一个服务发生故障，其他服务不会受到影响。同时数据层也按照业务往上垂直拆分。服务粒度变细后，新的问题又出现了。业务与服务的连接关系变得复杂。有什么好的优化方案吗？一般加入一个高可用的服务分布层集群，在设计协议的时候加入服务号，可以减少蜘蛛网式的依赖：(1)调用者依赖分布层，传入服务号(2)的分布层依赖服务层，通过服务号参数进行分布【一个数据库对应一个服务】数据访问服务最初是从DAO/ORM的数据访问需求来的，所以有的公司也有数据表和服务方式。一个子业务对应一个服务的玩法是：（1）服务层，整个群业务就是一个服务（2）存储层，实际上可能对应多个数据表，比如群信息，群成员，而群消息拆分成一个数据表一个服务，那么结构就会变成这样：群信息表、群成员表、群消息表和其他数据表也是解耦的，不会互相影响。【一个接口对应一个服务】在更极端的微服务架构中，甚至一个接口对应一个微服务。在这种情况下，架构演变为：（1）修改群信息服务（2）添加群信息服务（3）获取群信息服务多个服务操作同一个数据表，使用同一个缓存。如果每个接口出现故障，其他接口不会受到影响。3、细粒度的优缺点上面说了，不同粒度的服务化和微服务的优缺点是什么？总的来说，细粒度拆分的优点是：（1）服务可以独立部署（2）方便扩容和缩容，有利于提高资源利用率（3）拆解越细，耦合性越强相对减少(4)拆的越细，容错性相对越好，一个服务出问题不会影响到其他服务(5)扩展性更好(6)。细粒度拆分的缺点也很明显：（1）拆分的越细，系统越复杂（2）系统之间的依赖关系也越复杂（3）运维复杂度增加（4）监控越复杂（5）出现问题时更难定位问题（6）...关于微服务架构的“粒度”以及各个粒度的优劣，大家怎么看，欢迎补充，建设性意见会在后续文章中与大家分享。4.最后我们聊了很多。有网友询问作者对服务化和微服务粒度的看法。我个人认为用“子业务系统”的粒度作为微服务的单位比较合适：最后，在讨论完微服务架构的粒度之后，后续文章会跟大家聊聊微服务的最佳实践，短时间内发展服务化需要什么样的框架、组件、技术，接下来和大家聊一聊。文章转载自微信公众号《建筑师之路》
