优秀架构师修成之路( 五 ) _架构师

群发服务同样如此。由于在服务化架构里，我们使用 MySQL 和 Memcache 的方案，由于关系数据库的写入性能问题，中间还有队列以及相应的队列处理机，所有四个模块都有单独的机器提供服务，而在单元化架构里，四合一之后，只需要一套机器。当然机器的配置可能会有所提升，但真正计算之后你就会发现其实影响微乎其微。原因除了前面介绍的硬件增长空间外，上架机器的基本配置变高也是一个原因。而且，在单元化方案里，当我们把缓存部署在本地之后，其性能还有了额外的 20% 提升。
一些业务特有问题不过群发这个场景，我们也遇到了一些特定的问题，一是分区问题，一是作业管理。这里也与各位分享下我们的解决方法。
1, 分区问题
分区问题其实是每个服务都会遇到的，但单元化后的挑战在于让所有服务都适配同一分区算法，在我们的场景下，我们按照接收者进行了分区，即从底层往上，每一层都来适配此分区算法。
这里有特例的是用户特征和屏蔽服务，由于总体容量都很小，我们就没有对数据进行分区，所有单元内都是同一套全量数据，都是一个外部全量库的从库。不过由于本单元内的上层服务的关系，只有属于本分区的用户数据被访问到。所以，适配同一分区算法在某种程度上讲，可以兼容即可。
2, 作业管理
按照前面的分区方式，将群发服务的整体架构变成了一个类似 Scatter-Gather+CQRS 的方案，因为 Gather 不是一个请求处理的必须要素。也就是说，一个群发请求会被扩散到所有单元中，每个单元都要针对自己分区内的用户处理这个群发请求。
广播方式的引入，使得我们首先需要在前端机进行分单元作业的处理监控，我们在此增加了持久化队列来解决。同时，由于单元内每个服务也都是单独维护的，作业可能在任何时间中断，因此每个作业在单元内的状态也都是有记录的，以此来达到作业的可重入和幂等性，也就可以保证每个作业都可以在任何时间重做，但不会重复执行。
除此之外，我们还对服务器进行了更为精细的控制，使用 CPU 绑定提高多服务集成部署时的整体效率，使用多硬盘设计保证每个服务的 IO 性能，通过主从单元的读写分离来提高整体服务等等。
参考文章：https://www.infoq.cn/article/how-weibo-do-unit-architecture/SOA架构SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：

可从企业外部访问；
随时可用；
粗粒度的服务接口分级；
松散耦合；
可重用的服务；
服务接口设计管理；
标准化的服务接口；
支持各种消息模式；
精确定义的服务契约。

为了实现 SOA，企业需要一个服务架构，下图显示了一个例子：

文章插图

在上图中，服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。
此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
微服务架构先来看看传统的 web 开发方式，通过对比比较容易理解什么是 Microservice Architecture 。和 Microservice 相对应的，这种方式一般被称为 Monolithic（单体式开发）。
所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI 等所有逻辑。