1. Why should the Internet architecture be service- oriented ?
In the last article, I communicated with you. With the growth of data volume, concurrency, and business complexity, the following problems will occur in the Internet architecture:
( 1 ) Code is copied everywhere
( 2 ) Diffusion of underlying complexity
( 3 ) Basic library ( so/jar/dll ) coupling
( 4 ) SQL quality cannot be guaranteed, and business affects each other
( 5 ) Database coupling
"Service-oriented" is a good solution to the above pain points .
Many comments also put forward many constructive points, which are summarized and shared with you:
@tianwei classmate mentioned:
After serviceization, the problem of distributed transactions may arise . "No one is willing to introduce distributed transactions. When splitting based on the business level, business experts are required to intervene to reasonably split the serviceization, and then the service will be highly cohesive in the future. Transactions can guarantee that for boasting service calls, through compensation and other means, as long as final consistency is sufficient, after all, even current bank transfers are not strongly consistent.”
As @tianwei said, distributed transaction is a problem that the industry has not completely solved, and any architectural design is a compromise, throughput? Latency? consistency? Which is the main contradiction and which problem should be solved first. When big data, high concurrency, and business complexity are the main contradictions, perhaps "eventual consistency" is a better alternative to "transactions", or a solution acceptable to the business.
@hou diandian classmate mentioned:
With an additional layer of service layer, the architecture is actually more complex . A series of mechanisms need to be introduced to manage services. Attention should be paid to RPC service:
( 1 ) When the RPC service times out, the service caller should have some coping strategies, such as retransmission
( 2 ) For key services such as payment, pay attention to idempotency, because retransmission will lead to repeated operations
( 3 ) Multiple services should consider concurrent operations, rather a single-service lock mechanism such as synchronized in JAVA
@黄明 classmate mentioned:
After serviceization, with the expansion of scale, "service governance" must be considered , otherwise the dependencies between services will be messed up
2. The Internet microservice architecture is only suitable for "micro"
Everyone also agrees that with the increase in data volume, traffic, and business complexity, service-oriented architecture is the only way in the evolution of the architecture. The topic to be discussed today is: How many "micro" is a microservice architecture suitable?
[Coarse-grained: a service layer]
The roughest way to play is that all basic data are accessed through a service , which is fine when the business is not particularly complicated. Once the business becomes complicated, the service layer will become very heavy and become one of the coupling points . Scenario as an example , assuming there is a general service layer to access basic data, this service layer may look like this:
有一个统一的service层，用户信息，好友信息，群组信息，消息信息都通过这个service层来走。
细节：微信单对单消息是一个写多读少的业务，故没有缓存。
【一个子业务一个service】
如果所有的信息存储都在一个service里，那么一个地方出bug，就将影响整个业务，所以更合理的做法是在服务层进行细分，架构如何细分？垂直拆分是个好的方案，将子业务一个个拆出来，那么微信的服务化架构或许会变成这个样子：
（1）用户相关的子业务有user-service
（2）好友相关的子业务有friend-service
（3）群组相关的子业务有group-service
（4）消息相关的子业务有msg-service
这样的话，一个service出问题也不会影响其他service，同时数据层也按照业务垂直拆分开了。
服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么？
常见的，加入一个高可用服务分发层集群，并在协议设计时加入服务号，可以减少蜘蛛网状的依赖关系：
（1）调用方依赖分发层，传入服务号
（2）分发层依赖服务层，通过服务号参数分发
【一个数据库对应一个service】
数据访问service最初是从DAO/ORM的数据访问需求过来的，所以有些公司也有一个数据表一个service的玩法。
一个子业务对应一个service的玩法是：
（1）服务层，整个群业务是一个service
（2）存储层，实际可能对应了群信息、群成员、群消息等多个数据表
拆分成一个数据表一个service，则架构会变成这样：
群信息表，群成员表，群消息表等各个数据表之间也解耦开了，不会相互影响了。
【一个接口对应一个service】
微服务架构中更极端的，甚至一个接口对应一个微服务，这样的话，架构就从：
演化为：
（1）修改群信息服务
（2）增加群信息服务
（3）获取群信息服务
多个服务操纵同一个数据表，使用同一片缓存，每个接口出问题，都不会影响其他接口。
三、粒度粗细的优劣
上文中谈到的服务化与微服务，不同粒度的服务化各有什么优劣呢？
总的来说，细粒度拆分的优点有：
（1）服务都能够独立部署
（2）扩容和缩容方便，有利于提高资源利用率
（3）拆得越细，耦合相对会减小
（4）拆得越细，容错相对会更好，一个服务出问题不影响其他服务
（5）扩展性更好
（6）…
细粒度拆分的不足也很明显：
（1）拆得越细，系统越复杂
（2）系统之间的依赖关系也更复杂
（3）运维复杂度提升
（4）监控更加复杂
（5）出问题时定位问题更难
（6）…
关于微服务架构的“粒度”问题，以及各粒度的优劣，大伙有什么好的看法，欢迎补充，建设性的意见将在后续文中和大伙share。
四、结束的话
聊了许多，有网友问，笔者对待服务化以及微服务粒度的看法，个人觉得，以“子业务系统”粒度作为微服务的单位是比较合适的：