基于消息的分布式架构
在企业应用系统领域，我们总是会面对不同系统之间的通信、集成与整合，尤其当面临异构系统时，这种分布式的调用与通信变得越重要，它在架构设计中就更加凸显其价值。并且，从业务分析与架构质量的角度来讲，我们也希望在系统架构中尽可能地形成对服务的重用，通过独立运行在进程中服务的形式，彻底解除客户端与服务端的耦合。这常常是架构演化的必然道路。
随着网络基础设施的逐步成熟，从RPC进化到Web Service，并在业界开始普遍推行SOA，再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广，分布式架构在企业应用中开始呈现出不同的风貌，然而殊途同归，这些分布式架构的目标仍然是希望回到建造巴别塔的时代，系统之间的交流不再为不同语言与平台的隔阂而产生障碍。正如Martin Fowler在《企业集成模式》一书的序中写道：“集成之所以重要是因为相互独立的应用是没有生命力的。我们需要一种技术能将在设计时并未考虑互操作的应用集成起来，打破它们之间的隔阂，获得比单个应用更多的效益”。这或许是分布式架构存在的主要意义。
1、集成模式中的消息模式
归根结底，企业应用系统就是对数据的处理，而对于一个拥有多个子系统的企业应用系统而言，它的基础支撑无疑就是对消息的处理。与对象不同，消息本质上是一种数据结构（当然，对象也可以看做是一种特殊的消息），它包含消费者与服务双方都能识别的数据，这些数据需要在不同的进程（机器）之间进行传递，并可能会被多个完全不同的客户端消费。在众多分布式技术中，消息传递相较文件传递与远程过程调用（RPC）而言，似乎更胜一筹，因为它具有更好的平台无关性，并能够很好地支持并发与异步调用。对于Web Service与RESTful而言，则可以看做是消息传递技术的一种衍生或封装。
常用的消息模式
在我参与过的所有企业应用系统中，无一例外地都采用（或在某些子系统与模块中部分采用）了基于消息的分布式架构。但是不同之处在于，让我们做出架构决策的证据却迥然而异，这也直接影响我们所要应用的消息模式。
消息通道（Message Channel）模式
我们常常运用的消息模式是Message Channel（消息通道）模式，如图1所示。
图1 Message Channel模式
消息通道作为在客户端（消费者，Consumer）与服务（生产者，Producer）之间引入的间接层，可以有效地解除二者之间的耦合。只要实现规定双方需要通信的消息格式，以及处理消息的机制与时机，就可以做到消费者对生产者的“无知”。事实上，该模式可以支持多个生产者与消费者。例如，我们可以让多个生产者向消息通道发送消息，因为消费者对生产者的无知性，它不必考虑究竟是哪个生产者发来的消息。
虽然消息通道解除了生产者与消费者之间的耦合，使得我们可以任意地对生产者与消费者进行扩展，但它又同时引入了各自对消息通道的依赖，因为它们必须知道通道资源的位置。要解除这种对通道的依赖，可以考虑引入Lookup服务来查找该通道资源。例如，在JMS中就可以通过JNDI来获取消息通道Queue。若要做到充分的灵活性，可以将与通道相关的信息存储到配置文件中，Lookup服务首先通过读取配置文件来获得通道。
消息通道通常以队列的形式存在，这种先进先出的数据结构无疑最为适合这种处理消息的场景。微软的MSMQ、IBM MQ、JBoss MQ以及开源的RabbitMQ、Apache ActiveMQ都通过队列实现了Message Channel模式。因此，在选择运用Message Channel模式时，更多地是要从质量属性的层面对各种实现了该模式的产品进行全方位的分析与权衡。例如，消息通道对并发的支持以及在性能上的表现；消息通道是否充分地考虑了错误处理；对消息安全的支持；以及关于消息持久化、灾备（fail over）与集群等方面的支持。因为通道传递的消息往往是一些重要的业务数据，一旦通道成为故障点或安全性的突破点，对系统就会造成灾难性的影响。在本文的第二部
分，我将给出一个实际案例来阐释在进行架构决策时应该考虑的架构因素，并由此做出正确地决策。
发布者-订阅者（Publisher-Subscriber）模式
一旦消息通道需要支持多个消费者时，就可能面临两种模型的选择：拉模型与推模型。拉模型是由消息的消费者发起的，主动权把握在消费者手中，它会根据自己的情况对生产者发起调用。如图2所示：
图2 拉模型
拉模型的另一种体现则由生产者在状态发生变更时，通知消费者其状态发生了改变。但得到通知的消费者却会以回调方式，通过调用传递过来的消费者对象获取更多细节消息。
在基于消息的分布式系统中，拉模型的消费者通常以Batch Job的形式，根据事先设定的时间间隔，定期侦听通道的情况。一旦发现有消息传递进来，就会转而将消息传递给真正的处理器（也可以看做是消费者）处理消息，执行相关的业务。在本文第二部分介绍的医疗卫生系统，正是通过引入https://www.doczj.com/doc/93869702.html,实现了Batch Job，完成对消息通道中消息的处理。
推模型的主动权常常掌握在生产者手中，消费者被动地等待生产者发出的通知，这就要求生产者必须了解消费者的相关信息。如图3所示：
图3 推模型
对于推模型而言，消费者无需了解生产者。在生产者通知消费者时，传递的往往是消息（或事件），而非生产者自身。同时，生产者还可以根据不同的情况，注册不同的消费者，又或者在封装的通知逻辑中，根据不同的状态变化，通知不同的消费者。
两种模型各有优势。拉模型的好处在于可以进一步解除消费者对通道的依赖，通过后台任务去定期访问消息通道。坏处是需要引入一个单独的服务进程，以Schedule形式执行。而对于推模型而言，消息通道事实上会作为消费者观察的主体，一旦发现消息进入，就会通知消费者执行对消息的处理。无论推模型，拉模型，对于消息对象而言，都可能采用类似Observer模式的机制，实现消费者对生产者的订阅，因此这种机制通常又被称为Publisher- Subscriber模式，如图4所示：
图4 Publisher-Subscriber模式
通常情况下，发布者和订阅者都会被注册到用于传播变更的基础设施（即消息通道）上。发布者会主动地了解消息通道，使其能够将消息发送到通道中；消息通道一旦接收到消息，会主动地调用注册在通道中的订阅者，进而完成对消息内容的消费。
对于订阅者而言，有两种处理消息的方式。一种是广播机制，这时消息通道中的消息在出列的同时，还需要复制消息对象，将消息传递给多个订阅者。例如，有多个子系统都需要获取从CRM系统传来的客户信息，并根据传递过来的客户信息，进行相应的处理。此时的消息通道又被称为Propagation通道。另一种方式则属于抢占机制，它遵循同步方式，在同一时间只能有一个订阅者能够处理该消息。实现Publisher-Subscriber模式的消息通道会选择当前空闲的唯一订阅者，并将消息出列，并传递给订阅者的消息处理方法。
消息路由（Message Router）模式
无论是Message Channel模式，还是Publisher-Subscriber模式，队列在其中都扮演了举足轻重的角色。然而，在企业应用系统中，当系统变得越来越复杂时，对性能的要求也会越来越高，此时对于系统而言，可能就需要支持同时部署多个队列，并可能要求分布式部署不同的队列。这些队列可以根据定义接收不同的消息，例如订单处理的消息，日志信息，查询任务消息等。这时，对于消息的生产者和消费者而言，并不适宜承担决定消息传递路径的职责。事实上，根据S单一职责原则，这种职责分配也是不合理的，它既不利于业务逻辑的重用，也会造成生产者、消费者与消息队列之间的耦合，从而影响系统的扩展。
既然这三种对象（组件）都不宜承担这样的职责，就有必要引入一个新的对象专门负责传递路径选择的功能，这就是所谓的Message Router模式，如图5所示：
图5 Message Router模式
通过消息路由，我们可以配置路由规则指定消息传递的路径，以及指定具体的消费者消费对应的生产者。例如指定路由的关键字，并由它来绑定具体的队列与指定的生产者（或消费者）。路由的支持提供了消息传递与处理的灵活性，也有利于提高整个系统的消息处理能力。同时，路由对象有效地封装了寻找与匹配消息路径的逻辑，就好似一个调停者（Meditator），负责协调消息、队列与路径寻址之间关系。
除了以上的模式之外，Messaging模式提供了一个通信基础架构，使得我们可以将独立开发的服务整合到一个完整的系统中。Message Translator模式则完成对消息的解析，使得不同的消息通道能够接收和识别不同格式的消息。而且通过引入这样的对象，也能够很好地避免出现盘根错节，彼此依赖的多个服务。Message Bus模式可以为企业提供一个面向服务的体系架构。它可以完成对消息的传递，对服务的适配与协调管理，并要求这些服务以统一的方式完成协作。
2、消息模式的应用场景
基于消息的分布式架构总是围绕着消息来做文章。例如可以将消息封装为对象，或者指定消息的规范例如SOAP，或者对实体对象的序列化与反序列化。这些方式的目的只有一个，就是将消息设计为生产者和消费者都能够明白的格式，并能通过消息通道进行传递。
场景一：基于消息的统一服务架构
在制造工业的CIMS系统中，我们尝试将各种业务以服务的形式公开给客户端的调用者，例如定义这样的接口：
public interface IService {
IMessageExecute(IMessageaMessage);
voidSendRequest(IMessageaMessage);
}
之所以能够设计这样的服务，原因在于我们对业务信息进行了高度的抽象，以消息的形式在服务之间传递。此时的消息其实是生产者与消费者之间的契约或接口，只要遵循这样的契约，按照规定的格式对消息进行转换与抽取，就能很好地支持系统的分布式处理。
在这个CIMS系统中，我们将消息划分为ID，Name和Body，通过定义如下的接口方法，可以获得消息主体的相关属性：
public interface IMessage:ICloneable {
stringMessageID { get; set; }
stringMessageName() { get; set; }
IMessageItemSequenceCreateMessageBody();
IMessageItemSequenceGetMessageBody();
}
消息主体类Message实现了IMessage接口。在该类中，消息体Body为IMessageItemSequence
类型。这个类型用于获取和设置消息的内容：Value和Item：
public interface IItemValueSetting {
stringgetSubValue(string name);
voidsetSubValue(string name, string value);
}
public interface IMessageItemSequence:IItemValueSetting, ICloneable { IMessageItemGetMessageItem(string aName);
IMessageItemCreateMessageItem(string aName);
}
Value为字符串类型，它利用了HashTable存储Key和Value的键值对。Item则为IMessageItem
类型，在IMessageItemSequence的实现类中，同样利用了HashTable存储Key和Item的键值对。
IMessageItem支持消息体的嵌套。它包含了两部分：SubValue和SubItem。实现的方式和IMessageItemSequence相似。通过定义这样的嵌套结构，使得消息的扩展成为可能。一般的消息
结构如下所示：
各个消息对象之间的关系如图6所示：
图6 消息对象之间的关系
在实现服务进程通信之前，我们必须定义好各个服务或各个业务的消息格式。通过消息体的方法在服务的一端设置消息的值，然后发送，并在服务的另一端获得这些值。例如发送消息端定义如下的消息体：
IMessageFactory factory = new MessageFactory();
IMessage message = factory.CreateMessage();
message.SetMessageName("service1");
IMessageItemSequence body = message.CreateMessageBody();
body.SetSubValue("subname1","subvalue1");
body.SetSubValue("subname2","subvalue2");
IMessageItem item1 = body.CreateMessageItem(”item1”);
item1.SetSubValue("subsubname11","subsubvalue11");
item1.SetSubValue("subsubname12","subsubvalue12"); //Send Request Message MyServiceClient service = new MyServiceClient("Client"); service.SendRequest(message);
我们在客户端引入了一个ServiceLocator对象，它通过MessageQueueListener对消息队列进行侦听，一旦接收到消息，就获取该消息中的name去定位它所对应的服务，然后调用服务的Execute(aMessage)方法，执行相关的业务。
ServiceLocator承担的定位职责其实是对存储在ServiceContainer容器中的服务进行查询。ServiceContainer容器可以读取配置文件，在启动服务的时候初始化所有的分布式服务（注意，这些服务都是无状态的），并对这些服务进行管理。它封装了服务的基本信息，诸如服务所在的位置，服务的部署方式等，从而避免服务的调用者直接依赖于服务的细节，既减轻了调用者的负担，还能够较好地实现服务的扩展与迁移。
在这个系统中，我们主要引入了Messaging模式，通过定义的IMessage接口，使得我们更好地对服务进行抽象，并以一种扁平的格式存储数据信息，从而解除服务之间的耦合。只要各个服务就共用的消息格式达成一致，请求者就可以不依赖于接收者的具体接口。通过引入的Message对象，我们就可以建立一种在行业中通用的消息模型与分布式服务模型。事实上，基于这样的一个框架与平台，在对制造行业的业务进行开发时，开发人员最主要的活动是与领域专家就各种业务的消息格式进行讨论，这样一种面向领域的消息语言，很好地扫清了技术人员与业务人员的沟通障碍；同时在各个子系统之间，我们也只需要维护服务间相互传递的消息接口表。每个服务的实现都是完全隔离的，有效地做到了对业务知识与基础设施的合理封装与隔离。
对于消息的格式和内容，我们考虑引入了Message Translator模式，负责对前面定义的消息结构进行翻译和解析。为了进一步减轻开发人员的负担，我们还可以基于该平台搭建一个消息-对象-关系的映射框架，引入实体引擎（Entity Engine）将消息转换为领域实体，使得服务的开发者能够以完全面向对象的思想开发各个服务组件，并通过调用持久层实现消息数据的持久化。同时，利用消息总线（此时的消息总线可以看做是各个服务组件的连接器）连接不同的服务，并允许异步地传递消息，对消息进行编码。这样一个基于消息的分布式架构如图7所示：
图7 基于Message Bus的CIMS分布式架构
场景二：消息中间件的架构决策
在一个医疗卫生系统中，我们面临了客户对系统性能/可用性的非功能需求。在我们最初启动该项目时，客户就表达了对性能与可用性的特别关注。客户希望最终用户在进行复杂的替换删除操作时，能够具有很好的用户体验，简言之，就是希望能够快速地得到操作的响应。问题在于这样的替换删除操作需要处理比较复杂的业务逻辑，同时牵涉到的关联数据量非常大，整个操作若需完成，最坏情况下可能需要几分钟的时间。我们可以通过引入缓存、索引、分页等多种方式对数据库操作进行性能调优，但整个操作的耗时始终无法达到客户的要求。由于该系统是在一个遗留系统的基础上开发，如果要引入Map-Reduce来处理这些操作，以满足质量需求，则对架构的影响太大，且不能很好地重用之前系统的某些组件。显然，付出的成本与收益并不成正比。
通过对需求进行分析，我们注意到最终客户并不需要实时获得结果，只要能够保证最终结果的一致性和完整性即可。关键在于就用户体验而言，他们不希望经历漫长的等待，然后再通知他们操作究竟是成功还是失败。这是一个典型需要通过后台任务进行异步处理的场景。
在企业应用系统中，我们常常会遭遇这样的场景。我们曾经在一个金融系统中尝试通过自己编写任务的方式来控制后台线程的并发访问，并完成对任务的调度。事实证明，这样的设计并非行之有效。对于这种典型的异步处理来说，基于消息传递的架构模式才是解决这一问题的最佳办法。
因为消息中间件的逐步成熟，对于这一问题的架构设计，已经由原来对设计实现的关注转为如何进行产品选型和技术决策。
通过分析业务场景以及客户性质，我们发现该业务场景具有如下特征：
?在一些特定情形下，可能会集中发生批量的替换删除操作，使得操作的并发量达到高峰；例如FDA要求召回一些违规药品时，就需要删除药品库中该药品的信息；
?操作结果不要求实时性，但需要保证操作的可靠性，不能因为异常失败而导致某些操作无法进行；
?自动操作的过程是不可逆转的，因此需要记录操作历史；
?基于性能考虑，大多数操作需要调用数据库的存储过程；
?操作的数据需要具备一定的安全性，避免被非法用户对数据造成破坏；
?与操作相关的功能以组件形式封装，保证组件的可重用性、可扩展性与可测试性；
?数据量可能随着最终用户的增多而逐渐增大；
针对如上的业务需求，我们决定从以下几个方面对各种技术方案进行横向的比较与考量。
?并发：选择的消息队列一定要很好地支持用户访问的并发性；
?安全：消息队列是否提供了足够的安全机制；
?性能伸缩：不能让消息队列成为整个系统的单一性能瓶颈；
?部署：尽可能让消息队列的部署更为容易；
?灾备：不能因为意外的错误、故障或其他因素导致处理数据的丢失；
?API易用性：处理消息的API必须足够简单、并能够很好地支持测试与扩展；
我们先后考察了MSMQ、Resque、ActiveMQ和RabbitMQ，通过查询相关资料，以及编写Spike代码验证相关质量，我们最终选择了RabbitMQ。
我们选择放弃MSMQ，是因为它严重依赖Windows操作系统；它虽然提供了易用的GUI方便管理人员对其进行安装和部署，但若要编写自动化部署脚本，却非常困难。同时，MSMQ的
队列容量不能查过4M字节，这也是我们无法接收的。Resque的问题是目前仅支持Ruby的客户端调用，不能很好地与.NET平台集成。此外，Resque对消息持久化的处理方式是写入到Redis 中，因而需要在已有RDBMS的前提下，引入新的Storage。我们比较倾心于ActiveMQ与RabbitMQ，但通过编写测试代码，采用循环发送大数据消息以验证消息中间件的性能与稳定性时，我们发现ActiveMQ的表现并不太让人满意。至少，在我们的询证调研过程中，ActiveMQ会因为频繁发
送大数据消息而偶尔出现崩溃的情况。相对而言，RabbitMQ在各个方面都比较适合我们的架构要求。
例如在灾备与稳定性方面，RabbitMQ提供了可持久化的队列，能够在队列服务崩溃的时候，将未处理的消息持久化到磁盘上。为了避免因为发送消息到写入消息之间的延迟导致信息丢失，RabbitMQ引入了Publisher Confirm机制以确保消息被真正地写入到磁盘中。它对Cluster的支持提供了Active/Passive与Active/Active两种模式。例如，在Active/Passive模式下，一旦一个节点失败，Passive节点就会马上被激活，并迅速替代失败的Active节点，承担起消息传递的职责。如图8所示：
图8 Active/Passive Cluster
在并发处理方面，RabbitMQ本身是基于erlang编写的消息中间件，作为一门面向并发处理
的编程语言，erlang对并发处理的天生优势使得我们对RabbitMQ的并发特性抱有信心。RabbitMQ
可以非常容易地部署到Windows、Linux等操作系统下，同时，它也可以很好地部署到服务器集
群中。它的队列容量是没有限制的（取决于安装RabbitMQ的磁盘容量），发送与接收信息的性
能表现也非常好。RabbitMQ提供了Java、.NET、Erlang以及C语言的客户端API，调用非常简
单，并且不会给整个系统引入太多第三方库的依赖。例如.NET客户端只需要依赖一个程序集。
即使我们选择了RabbitMQ，但仍有必要对系统与具体的消息中间件进行解耦，这就要求我
们对消息的生产者与消费者进行抽象，例如定义如下的接口：
public interface IQueueSubscriber {
voidListenTo
voidListenTo
Predicate
voidListenTo
Predicate
boolrequeueFailedMessages);
}
public interface IQueueProvider {
T Pop
T PopAndAwaitAcknowledgement
Predicate
T PopAndAwaitAcknowledgement
Predicate
boolrequeueFailedMessages);
void Push(FunctionalAreafunctionalArea, string routingKey, object
payload);
}
在这两个接口的实现类中，我们封装了RabbitMQ的调用类，例如：
public class RabbitMQSubscriber : IQueueSubscriber { public void ListenTo
using (IConnection connection = _factory.OpenConnection())
using (IModel channel = connection.CreateModel()) { var consumer = new QueueingBasicConsumer(channel);
stringconsumerTag = channel.BasicConsume(queueName,
AcknowledgeImmediately, consumer);
var response = (BasicDeliverEventArgs)
consumer.Queue.Dequeue();
varserializer = new JavaScriptSerializer();
stringjson = Encoding.UTF8.GetString(response.Body);
var message = serializer.Deserialize
action(message);
}
}
}
public class RabbitMQProvider : IQueueProvider {
public T Pop
varreturnVal = default(T);
constboolacknowledgeImmediately = true;
using (var connection = _factory.OpenConnection())
using (var channel = connection.CreateModel())
{
var response = channel.BasicGet(queueName,
acknowledgeImmediately);
if (response != null) {
varserializer = new JavaScriptSerializer();
varjson = Encoding.UTF8.GetString(response.Body);
returnVal = serializer.Deserialize
}
}
returnreturnVal;
}
}
我们用https://www.doczj.com/doc/93869702.html,来实现Batch Job。通过定义一个实现了IStatefulJob接口的Job类，在
Execute()方法中完成对队列的侦听。Job中RabbitMQSubscriber类的ListenTo()方法会调用Queue
的Dequeue()方法，当接收的消息到达队列时，Job会侦听到消息达到的事件，然后以同步的方
式使得消息弹出队列，并将消息作为参数传递给Action委托。因此，在Batch Job的Execute()
方法中，可以定义消息处理的方法，并调用RabbitMQSubscriber类的ListenTo()方法，如下所示
（注意，这里传递的消息事实上是Job的Id）：
public void Execute(JobExecutionContext context) { stringqueueName =
queueConfigurer.GetQueueProviders()https://www.doczj.com/doc/93869702.html,;
try {
queueSubscriber.ListenTo
job =>request.MakeRequest(job.Id.ToString()));
} catch(Exception err) {
Log.WarnFormat("Unexpected exception while processing queue
'{0}', Details: {1}", queueName, err);
}
}
队列的相关信息例如队列名都存储在配置文件中。Execute()方法调用了request对象的
MakeRequest()方法，并将获得的消息（即JobId）传递给该方法。它会根据JobId到数据库中查
询该Job对应的信息，并执行真正的业务处理。
在对基于消息处理的架构进行决策时，除了前面提到的考虑因素外，还需要就许多设计细节
进行多方位的判断与权衡。例如针对Job的执行以及队列的管理，就需要考虑如下因素：
?对Queue中Job状态的监控与查询；
?对Job优先级的管理；
?能否取消或终止执行时间过长的Job；
?是否能够设定Job的执行时间；
?是否能够设定Poll的间隔时间；
?能否跨机器分布式的放入Job；
?对失败Job的处理；
?能否支持多个队列，命名队列；
?能否允许执行Job的工作进程对应特定的队列；
?对Dead Message的支持。
3、选择的时机
究竟在什么时候，我们应该选择基于消息处理的分布式架构？根据我参与的多个企业应用系统的经验，窃以为需要满足如下几个条件：
?对操作的实时性要求不高，而需要执行的任务极为耗时；
?存在企业内部的异构系统间的整合；
?服务器资源需要合理分配与利用；
对于第一种情况，我们常常会选择消息队列来处理执行时间较长的任务。此时引入的消息队列就成了消息处理的缓冲区。消息队列引入的异步通信机制，使得发送方和接收方都不用等待对方返回成功消息，就可以继续执行下面的代码，从而提高了数据处理的能力。尤其是当访问量和数据流量较大的情况下，就可以结合消息队列与后台任务，通过避开高峰期对大数据进行处理，就可以有效降低数据库处理数据的负荷。前面提到的医疗卫生系统正是这样一种适用场景。
对于不同系统乃至于异构系统的整合，恰恰是消息模式善于处理的场景。只要规定了消息的格式与传递方式，就可以有效地实现不同系统之间的通信。在为某汽车制造商开发一个大型系统时，分销商作为.NET客户端，需要将数据传递到管理中心。这些数据将被Oracle的EBS
（E-Business Suite）使用。分销商管理系统（Dealer Management System，DMS）采用了C/S结构，数据库为SQL Server，汽车制造商管理中心的EBS数据库为Oracle 10g。我们需要解决两种不同数据库间数据的传递。解决方案就是利用MSMQ，将数据转换为与数据库无关的消息数据，并在两端部署MSMQ服务器，建立消息队列以便于存储消息数据。实现架构如图9所示。
图10 利用MSMQ实现的分布式处理架构
首先，分销商的数据通过MSMQ传递到MSMQ Server，再将数据插入到SQL Server数据库的同时，利用FTP将数据传送到专门的文件服务器上。EBS App Server会将文件服务器中的文件，基于接口规范写入到Oracle数据库，从而实现.NET系统与Oracle系统之间的整合。
分布式系统通常能够缓解单个服务器的压力，通过将不同的业务操作与数据处理以不同的服务形式部署并运行在不同的服务器上，就可以有效地分配与利用服务器资源。在这种情况下，部署在不同服务器上的服务，既可能作为服务端，用以处理客户端调用的请求，也可能作为客户端，在处理完自己的业务后，将其余业务请求委派给其他服务。在早期的CORBA系统中，通过建立统一的Naming Service，用以管理和分派服务，并通过Event Service实现事件的分发与处理。但CORBA系统采用的是RPC的方式，需要将服务设计和部署为远程对象，并建立代理。如果通过消息通道的方式，则既可以解除这种对远程对象的依赖，又可以很好地支持异步调用模型。在前面提到的CIMS系统，就是通过消息总线提供消息传递的基础设施，并建立统一的消息处理服务模型，解除服务见的依赖，使得各个服务能够独立地部署到不同服务器上。
微服务系统设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。
前台门户网站架构 设计方案 北京宽连十方数字技术有限公司 2012-7 目录 1设计思路2
2系统结构3 3网络规划及性能计算错误!未定义书签。 3.1网络架构8 3.2网络架构说明错误!未定义书签。 3.2.1采用双防火墙双交换机做网络冗余，保障平台服务8 3.2.2采用硬件设备负载均衡器，实现网络流量的负载均衡8 3.3系统测算错误!未定义书签。 3.3.1系统处理能力要求34 3.3.2业务处理能力要求错误!未定义书签。 3.3.3系统话务模型错误!未定义书签。 3.4配置核算错误!未定义书签。 3.4.1数据库服务器性能核算错误!未定义书签。 3.4.2WEB服务器集群性能核算错误!未定义书签。 3.4.3WEB服务器集群内存性能核算错误!未定义书签。 3.4.4网络带宽35 4性能模拟测试及性能推算错误!未定义书签。 4.1测试环境错误!未定义书签。 4.2测试结果错误!未定义书签。 4.2.11个客户端模拟不同线和并发请求结果错误!未定义书签。 4.2.210个客户端请求错误!未定义书签。 4.3结果分析错误!未定义书签。 4.4根据测试结果推算错误!未定义书签。 4.5设备清单35 4.5.1硬件设备配置清单错误!未定义书签。 4.5.2设备技术规格错误!未定义书签。 4.6平台扩容的建议35 1 网站的性能瓶颈分析 网站的性能影响因素很多，下面主要从如下4个方面进行分析说明： 1) 网络负载 a) 公网负载 b) 内网负载
2) WEB应用服务器性能 a) CPU b) 存储，I/O访问 c) 内存 d) 并发TCP/IP连接数 3) 数据库服务器性能 a) 数据库参数配置 b) 服务器性能（CPU、内存、存储） c) 数据结构的合理性 4) 不同WEB应用的处理方式而对不同的性能瓶颈 a) 对于静态的网站： 静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一个静态HTML文档发出访问请求后，服务器端只是简单地将该文档传 输到客户端。从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。 对于静态HTML的访问瓶颈为：网络带宽、磁盘I/O以及cache(高速缓冲存储器)。 b) 对于动态页面 因为服务器解析动态页面必须在其传输到客户端前就通过服务器来进行解释，这样就会给应用服务器添加额外的性能消耗，如果进一步要访问数据库，则会增加数据库服务器 的性能消耗，则动态页面还有额外的瓶颈：应用服务器的性能，数据库服务器的性能。 2 系统架构设计 2.1 总体思路 为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计: 2.1.1 负载均衡 1)四层交换负载均衡： 采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载均 衡。 2)通过第三方软件来实现负载均衡,同时实现页面请求的缓存。 通过Nginx实现反向代理服务器集群，同时搭建squid集群以作为静态页面和图片的缓存。 3)通过web服务器的配置来实现负载均衡 即通过apache或是Nginx 将客户请求均衡的分给tomcat1,tomcat2....去处理。
微服务架构的部署 本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。 本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下： 首先，该系统具有典型分布式应用系统特征： 该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败； 系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用； 由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。 其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。 第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。 针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。 开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。 代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。
大型电商分布式架构设计与优化 本文主题为电商网站架构案例，将介绍如何从电商网站的需求，到单机架构，逐步演变为常用的、可供参考的分布式架构原型。除具备功能需求外，还具备一定的高性能、高可用、可伸缩、可扩展等非功能质量需求（架构目标）。
本文大纲： 1. 使用电商案例的原因 2. 电商网站需求 3. 网站初级架构 4. 系统容量估算 5. 网站架构分析 6. 网站架构优化 根据实际需要，进行改造、扩展、支持千万PV，是没问题的。 使用电商案例的原因 分布式大型网站，目前看主要有几类： 1.大型门户（比如网易、新浪等）； 2.SNS网站（比如校内、开心网等）； 3.电商网站（比如阿里巴巴、京东商城、国美在线、汽车之家等）。
大型门户一般是新闻类信息，可以使用CDN、静态化等方式优化。而开心网等交互性比较多，可能会引入更多的NoSQL、分布式缓存、使用高性能的通信框架等。电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NoSQL等技术。因此，我们采用电商网站作为案例，进行分析。 电商网站需求 客户需求： ?建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款； ?用户购买时可以在线与客服沟通； ?用户收到商品后，可以给商品打分和评价； ?目前有成熟的进销存系统，需要与网站对接； ?希望能够支持3~5年，业务的发展； ?预计3~5年用户数达到1000万； ?定期举办双11、双12、三八男人节等活动； ?其他的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导、挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业以及参考网站，给客户提供方案。其它的这里暂不展开。
一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。 大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。 上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。 1、HTML静态化 其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。 除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。 同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
关于举办“微服务架构设计与实战”高级培训班的通知 各有关单位： 作为一种新的设计和架构理念，微服务自2014年首次提出就引发了业界激烈的讨论。同时，Docker技术的迅速发展，也让微服务架构的实施变得更加容易。相比于传统的单体式应用而言，微服务这种小而化之、互相连接的设计理念不仅能让复杂应用的构建变得更加灵活，更能帮助创业企业在面对市场的高度不确定性时，快速推出新产品，低成本试错。那么，企业究竟该如何去设计、开发和部署微服务到自己的业务中去?如何做好服务发现和服务治理呢?中国软件产业培训网决定在举办“微服务架构设计与实战培训班”望各单位收到通知后组织相关人员参加。现将有关事宜通知如下： 一、培训时间及地点 2019年12月20日-12月23日北京 2020年01月10日-01月13日上海 二、主讲专家 程老师 CTO，微服务架构首席咨询师，国内较早倡导和实践微服务的先行者，多次受邀在大型技术会议主题分享“微服务架构”相关主题。超过10年以上的软件行业经验,从企业应用、互联网应用、服务化平台的架构设计、开发到自动化构建、持续集成、持续交付以及DevOps 的转型实施等有较丰富的实践经验。 范老师国内架构设计专家、多领域架构评审委员和技术架构组委员。信息技术领域具有坚实的学术背景和教学培训经验，多年研发和客户项目高级管理咨询能力，多年包括华为IPD 研发管理工作经历。善于用先进信息化技术架构和方法指导团队完成设计工作，具有雄厚的咨询能力。具有大型分布式团队的领导和管理经验。 三、培训特色 1. 理论与实践相结合、案例分析与行业应用穿插进行; 2. 专家精彩内容解析、学员专题讨论、分组研究;
某大型公司公司软件开发管理制度 版本：1.0 SDM审批： QA经理[时间] CTO[时间] 目录 1.目的和作用3 2.适用范围：3 3. 参考文件3 4.适用对象3 5.软件开发流程4 5.1可行性研究与计划4 5.1.1实施4 5.1.2 文档4 5.1.2.1 应交付的文档4 5.1.2.2 提交步骤4 5.2需求分析4 5.2.1实施4 5.2.2要求5 5.2.3交付文档5 5.2.4审批5 5.3概要设计5 5.3.1实施5 5.3.2要求6 5.3.3交付文档6 5.3.4补充说明6 5.3.5审批6 5.4详细设计7 5.4.1实施7 5.4.2要求7 5.4.3文档7 5.4.4审批7 5.5实现7 5.5.1实施与要求7 5.5.2交付文档8 5.5.3审批8 5.6组装测试8 5.6.1实施8 腹有诗书气自华
5.6.2要求8 5.6.3交付文档8 5.6.4审批8 5.7确认测试9 5.7.1实施9 5.7.2要求9 5.7.3交付文档9 5.7.4 补充说明9 5.7.5 审批9 5.8发布10 5.8.1过程10 5.8.2 文档10 5.8.3 审核10 5.9 交接10 6. 附录1：项目文档清单11 1.目的和作用 本流程详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 2.适用范围： 公司的软件开发产品均适用。 3. 参考文件 各种文档模板 文档命名规则 交接流程 4.适用对象 软件管理人员，软件开发人员，软件维护人员 5.软件开发流程 5.1可行性研究与计划 5.1.1实施 5.1.1.1 软件开发部分析人员进行市场调查与分析，确认软件的市场需求 5.1.1.2 在调查研究的基础上进行可行性研究，写出可行性报告 5.1.1.3 评审和审批，决定项目取消或继续 5.1.1.4 若项目可行，制订初步的软件开发计划，建立项目日志 5.1.1.5 根据市场环境、公司软硬件情况预测十大风险因素 5.1.2 文档 5.1.2.1 应交付的文档 1）可行性研究报告* 2）初步的软件开发计划 3）十大风险列表* 腹有诗书气自华
大型网络平台架构设计方案
目录 1网站的性能瓶颈分析 (1) 2系统架构设计 (3) 2.1总体思路 (3) 2.1.1负载均衡 (3) 2.1.2WEB应用开发架构思路 (3) 2.1.3数据存储的设计思路 (3) 2.1.4不同网络用户访问考虑 (4) 2.2总体架构 (5) 2.2.1网站的系统分层架构 (5) 2.2.2网站的物理架构 (6) 2.2.3网站的开发架构 (7) 2.2.4网络拓扑结构 (8) 2.3架构涉及技术的详解 (9) 2.3.1负载均衡 (9) 2.3.2缓存 (15) 2.3.3页面静态化 (19) 2.3.4数据库配置及优化 (20) 2.3.5文件存储 (21) 2.3.6网络问题解决方案 (24) 2.3.7WEB应用开发架构设计思路 (26) 2.4系统软件参数优化 (30) 2.4.1操作系统优化 (30) 2.4.2tomcat服务器优化 (31) 2.4.3apache服务器优化 (33) 2.4.4Nginx服务器的优化 (33) 3WEB服务架构评测 (34) 3.1测试环境 (34) 3.1.1网络环境 (34)
3.1.2服务器配置 (35) 3.1.3软件环境 (35) 3.2测试结果 (40) 3.2.1单个TOMCAT的WEB服务器 (40) 3.2.2Nginx+2个TOMCAT的WEB服务器 (41) 3.2.3Nginx+2个TOMCAT的WEB服务器+缓冲 (42) 3.3测试结果分析 (43) 3.4评测结果 (44) 4配置选型 (45) 4.1网络带宽 (45) 4.2架构和硬件配置选型 (46) 4.2.1硬件配置参考 (46) 4.2.2Web架构和硬件选型 (47) 4.3硬件扩容策略 (48) 4.3.1增加服务器 (48) 4.3.2增加存储 (48) 4.3.3升级服务器 (48) 4.3.4网络扩容 (48) 5附录：一些主流网站的真实数据 (49)
可适应高并发的城市级智慧平台系统架构设计策略应用 发表时间：2018-10-15T17:17:20.863Z 来源：《防护工程》2018年第13期作者：袁华辉[导读] 城市级智慧服务（管理）平台对于提升城市智能化水平、提高政府城市管理效率，方便市民具有较大意义 袁华辉 武汉市城投停车场投资建设管理有限公司湖北武汉 430015 摘要:城市级智慧服务（管理）平台对于提升城市智能化水平、提高政府城市管理效率，方便市民具有较大意义。好的城市智慧平台必须具有较强的安全性、稳定性以及应对高并发的能力。本文从实用的角度介绍城市级平台在架构设计中的技巧和策略，侧重提供了适应高并发的系统架构设计解决方案。 关键词:高并发、智慧系统、架构设计 一、QPS是城市智慧系统架构设计的重要因素 搭建城市级的智慧应用系统，必须考虑大量用户同时使用客户端访问系统平台的极端情况。除了考虑系统的安全性、稳定性等因素外，系统架构的设计依据必须基于QPS（每秒请求数），以提高系统应对突然的高并发性可能性。不同的QPS对系统架构设计等技术要求原则如下： 50QPS以下——小网站 服务器性能稳定即可。 50～100QPS——DB极限型 须加强数据访问设计、代码优化，读写必须分离。 300～800QPS——带宽极限型 采取上缓存，多机负载均衡措施等。 500～1000QPS——内网带宽极限＋Memcache极限型采取数据分离、服务器集群、NOSQL措施。 1000～2000QPS——锁模式极限型 锁的问题会成为最大的瓶颈。要求系统中不能存在中央节点，所有的数据都必须分布存储、分布处理。 2000QPS以上——C10K极限 必须业务分离、分散QPS。 二、系统架构设计 （一）根据QPS选定架构模式 对于城市级应用系统而已必将免得大量的访问量、按照一般二线城市600万人口来计算，使用率每日可能达到1200万次。平均每日请求为每分钟8000次请求。安装业务进行估算：比如城市级智慧停车应用，高峰集中在上午7点30到9点半。下午的5点到7点这几个时间段。高峰期内平均每分钟请求约为10w次。QPS=1667，属于锁模式极限型，须采用分布式架构。 （二）应用服务器集群改善并发处理能力 单一的服务器由于系统、硬件等约束出来处理能力是非常有限的，所以我们需要我们应用能够横向扩展，向外扩展，也就就是Scale Out。 这是一个常规的分布式架构。通过负载代理到不同的服务器中，同时将文件、数据进行了分开部署。实测时，我们发现文件服务器和数据服务器压力还是非常大，需要进一步优化。 （三）使用缓存改善性能 随着对数据请求增多、用户量增多，数据库压力会慢慢凸显出来，访问延迟也就浮显出来。通常就简单的做法是采用缓存技术。其中在日常数据运用上，大部分的业务访问都集中小部分的数据上。可以将经常访问的数据缓存在内存中，这样可以减少数据库的访问压力。 \ 目前，我们的措施很大程度上提高了数据的响应时间。有了这些基本保障，下面就要着重解决锁的问题。锁主要有2类来源，一个文件读取和写入，一个数据库的读取和写入。解决锁的问题，也就是解决文件和数据问题。 （四）数据库读写分离 即使有缓存的支持，但若缓存过期、或者没有读取到缓存数据以及所有写操作还是需要访问数据库。为减轻数据库压力，故可将读、写操作分开，设计主数据库和从数据库。主数据库进行写的操作，从数据库响应所有的查询操作。主数据库每次完成了新的操作后，将数据同步到从数据库中（同步方法很多，在这里就不详细叙述了）。
1)软件开发工具范围：在高级程序设计语言的基础上，为提高软件开发的质量 和效率，从规划分析设计测试成本和管理各方面，对软件开发者提供各种不同程度的帮助的一类广泛的软件。应当为软件人员提供信息管理，信息存储一致性的保证提供帮助支持。 2)SDT 3个发展阶段：通用工具，专用工具，集成工具。 3)软件开发工具的概念：在高级程序设计语言后进一步发展的产物，目的是给 与人们在开发软件过程中不同方面和程度的支持或帮助，支持开发的全过程而不是仅限编码或其他特定工作阶段。 4)软件的意义：硬件是躯体，软件是灵魂；软件是用户和计算机的桥梁；软件 是人类知识与经验的结晶，一种新的载体。 5)通用软件弱点：许多工作无法完成，不能反映逻辑内涵，难于保持一致性。 6)专用软件弱点：对软件开发缺乏全面统一的支撑环境造成冲突和矛盾。 7)软件开发发展阶段：机器语言开发软件，汇编语言开发转换，高级语言开发 编译程序转换，各种软件开发工具完成编译程序转换。（项目管理版本控制软件重用新问题） 8)新的软件开发方法表现在四个方面特点：自动化程度提高，进一步向用户延 伸，延伸到项目版本管理扩展到不断发展生长完善的全过程。 9)4GL：非过程化的程序设计语言，针对以处理过程为中心的第三代语言他希 望通过某些标准处理过程的自动生成使用户可以只说明要求做什么，而把具体的执行步骤安排交给软件自动处理。 10)CASE:计算机辅助软件工程或计算机辅助系统工程，应用计算机自身处理信 息的巨大能力来帮助人们开发复杂的软件或应用系统，。 11)软件开发过程5阶段：初始要求提出需求分析（软件功能说明书），总体设 计，程序文档的编写，测试调试阶段，维护。 12)软件工作的困难体现：复杂性，多样性，可维护性，可重用性。 13)SDT功能（定性）：认识与描述客观系统，存储管理开发过程中的信息，代码 的编写生成，文档的编制生成，软件项目的管理。 14)SDT性能（定量）：表达能力或描述能力，保持信息一致性的能力，使用的方 便程度，工具的可靠程度，对软硬件环境的要求。 15)SDT划分：A按工作阶段分—设计工具，分析工具，计划工具 B 按集成程度分---单项，集成 C按与硬件软件的关系分—依赖于特定的计算机或软件，独立于 硬件与其他软件。 16)软件开发过程2个转换：用户的理解—程序员的理解---程序的实现。 17)大型软件开发的困难：一致性保持困难，测试的困难大大增加（水波效应）， 工作进度难以控制，文档与代码协调困难，版本更新带来的困难。 18)大型软件是现代化生产，单个程序是手工作坊。 19)困难产生的原因：大系统的复杂性，个人组织与协调的困难，各应用领域的 差别，时间和变化的因素。 20)用户任务：提出要求验收使用要求修改。程序员任务：编写程序文档，调试 自己编码的程序想项目负责人提交工作进展。项目负责人任务：分析需求，分配任务，验收联调，向用户交付使用，接受分析用户的修改要求布置修改任务验收修改成果并再提交。 21)结构化程序设计把程序的结构分解成3种基本模块：处理单元，循环机制，
互联网智能推荐系统架构设计
一，题记 58同城智能推荐系统大约诞生于2014年（C++实现），该套系统先后经历了招聘、房产、二手车、黄页和二手物品等产品线的推荐业务迭代，但该系统耦合性高，难以适应推荐策略的快速迭代。 58同城APP猜你喜欢推荐和推送项目在2016年快速迭代，产出了一套基于微服务架构的推荐系统（Java 实现），该系统稳定、高性能且耦合性低，支持推荐策略的快速迭代，大大提高了推荐业务的迭代效率。此后，我们对旧的推荐系统进行了重构，将所有业务接入至新的推荐系统，最终成功打造了统一的58同城智能推荐系统。 下面我们将对58同城智能推荐系统展开介绍，首先会概览整体架构，然后从算法、系统和数据三方面做详细介绍。 整体架构首先看一下58同城推荐系统整体架构，一共分数据层、策略层和应用层三层，基于58平台产生的各类业务数据和用户积累的丰富的行为数据，我们采用各类策略对数据进行挖掘分析，最终将结果应用于各类推荐场景。
二，数据层 主要包括业务数据和用户行为日志数据。业务数据主要包含用户数据和帖子数据，用户数据即58平台上注册用户的基础数据，这里包括C端用户和企业用户的信息，帖子数据即用户在58平台上发布的帖子的基础属性数据。 这里的帖子是指用户发布的房源、车源、职位、黄页等信息，为方便表达，后文将这些信息统称为帖子。用户行为日志数据来源于在前端和后台的埋点，例如用户在APP上的筛选、点击、收藏、打电话、微聊等各类操作日志。
这些数据都存在两种存储方式，一种是批量存储在HDFS上以用作离线分析，一种是实时流向Kafka以用作实时计算。 三，策略层 基于离线和实时数据，首先会开展各类基础数据计算，例如用户画像、帖子画像和各类数据分析，在这些基础数据之上便是推荐系统中最重要的两个环节：召回和排序。召回环节包括多种召回源的计算，例如热门召回、用户兴趣召回、关联规则、协同过滤、矩阵分解和DNN等。 我们采用机器学习模型来做推荐排序，先后迭代了LR、FM、GBDT、融合模型以及DNN，基于这些基础机器学习模型，我们开展了点击率、转化率和停留时长多指标的排序。 这一层的数据处理使用了多种计算工具，例如使用MapReduce和Hive做离线计算，使用Kylin做多维数据分析，使用Spark、DMLC做大规模分布式机器学习模型训练，使用theano和tensorflow做深度模型训练。 三，应用层 再往上就是应用层，我们通过对外提供rpc和http接口来实现推荐业务的接入。58同城的推荐应用大多是向用户展示一个推荐结果列表，属于topN推荐模式，这里介绍下58同城的几个重要的推荐产品：
前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： ?服务器 o均衡负载(如：nginx，阿里云SLB) o资源监控 o分布式 ?数据库 o主从分离，集群 o DBA 表优化，索引优化，等 o分布式 ?nosql o redis ?主从分离，集群 o mongodb ?主从分离，集群 o memcache ?主从分离，集群 ?cdn o html o css o js o image
高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。 测试高并发可以使用第三方服务器或者自己测试服务器，利用测试工具进行并发请求测试，分析测试数据得到可以支撑并发数量的评估，这个可以作为一个预警参考，俗话说知己自彼百战不殆。 第三方服务: ?阿里云性能测试 并发测试工具： ?Apache JMeter ?Visual Studio性能负载测试 ?Microsoft Web Application Stress Tool 实战方案 通用方案 日用户流量大，但是比较分散，偶尔会有用户高聚的情况； 场景：用户签到，用户中心，用户订单，等 服务器架构图： 说明： 场景中的这些业务基本是用户进入APP后会操作到的，除了活动日(618,双11，等)，这些业务的用户量都不会高聚集，同时这些业务相关的表都是大数据表，业务多是查询操作，所以我们需要减少用户直接命中DB的查询；优先查询缓存，如果缓存不存在，再进行DB查询，将查询结果缓存起来。 更新用户相关缓存需要分布式存储，比如使用用户ID进行hash分组，把用户分布到不同的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。
微服务架构设计
目录 一、微服务架构介绍 (3) 二、微服务出现和发展 (3) 三、传统开发模式和微服务的区别 (4) 四、微服务的具体特征 (7) 五、SOA和微服务的区别 (9) 六、怎么具体实践微服务 (11) 七、常见的设计模式和应用 (17) 八、优点和缺点 (23) 九、思考：意识的转变 (26)
一、微服务架构介绍 微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的 类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。 概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。 定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。 本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。 二、微服务出现和发展 微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年； 越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。 这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。
大型软件开发过程的质量管理体系 韩思音 弋陪余 国信朗讯科技网络技术有限公司是中国电信和朗讯科技合资的专业从事通信网络管理软件开发的高科技企业，公司位于上海浦东，注册资金２ ９８０万美元，员工达１５０人，本科以上学历超过９５％。公司在１９９９年成立后就开展了ＩＳＯ９００１贯标活动，并于２０００年８月通过了ＩＳＯ９００１认证。公司以贝尔试验室的大型软件开发管理流程为基础，建立了自己的ＩＳＯ９００１质量管理体系。三年来已经开发了“传输网络集中监控系统ＮｅｔＧｕａｒｄ”、“电信网络资源管理系统ＮｅｔＭａｓｔｅｒ”两个大型软件系统。通过ＩＳＯ９００１的贯标活动，加强了公司全体员工的质量意识，强化了软件开发过程的规范性，改进了软件开发过程，保证了软件开发的质量，对加强公司实力、提高市场形象起了很好的推动作用。 通过了ＩＳＯ９００１认证后，审核机构每年要进行一次复查，即监督审核。如果公司质量体系运行得不好，就可能被暂停证书；如发生重大事故，证书可能被撤消。除此以外，公司每年还进行一次内审，即公司内部对质量体系运行是否符合ＩＳＯ９００１标准进行的检查，各部门对内审发现的不符合项进行认真整改，由质量管理部验收。各部门对本部门的工作定期提出改进措施，由质量管理部对其进行验证，使质量体系不断改进。所以ＩＳＯ９００１的认证对企业的质量体系是有严格管理的，是有保证的。 １ 软件产品质量的特点 按照ＩＳＯ９１２６的定义，软件的质量通常可以从以下六个方面去衡量（定义）。 １）功用性（Ｆｕｎｃｔｉｏｎａｌｉｔｙ），即软件是否满足了客户功能要求。 ２）可靠性（Ｒｅｌｉａｂｉｌｉｔｙ），即软件是否能够一直在一个稳定的状态上满足可用性。 ３）可用性（Ｕｓａｂｉｌｉｔｙ），即衡量用户能够使用软件需要多大的努力。 ４）效率（Ｅｆｆｉｃｉｅｎｃｙ），即衡量软件正常运行需要耗费多少物理资源。 ５）可维护性（Ｍａｉｎｔａｉｎａｂｉｌｉｔｙ），即衡量对已经完成的软件进行调整需要多大的努力。 ６）可移植性（Ｐｏｒｔａｂｉｌｉｔｙ），即衡量软件是否能够方便地部署到不同的运行环境中。 可见，同其它产品相比，软件产品的质量有其明显的特殊性。
微服务架构落地最佳实践
难点1：“一步到位”的认知错觉 这些年微服务大红大紫，但是真正能够拿出来做为可实践的案例少之又少。大部分的微服务案例只能看到微服务架构的“演进结果”，但是看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰，却没有看到攀登高峰的路径。 这就给很多架构师一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。 这和很多团队自上而下的架构设计感受和相似。于是架构师们蜂拥而至，各种分析方法论层出不穷，讨论和分享络绎不绝。然而真正落地实施的却很少，使得微服务在网络上慢慢变成了一种“玄学”：微服务的实施在“理论研究”的阶段。 这违反了软件架构的最基本规律：架构是解决当前的需求和痛点演进的，而无法对没有出现的问题和痛点进行设计。因此，一步到位的整体的微服务架构设计完全没有必要。况且一个集中化的设计，很难体现微服务的轻量级优势。 我相信技术的发展一定是向不断降低成本的方向上发展的。如果新技术没有降低成本反而提升了成本，要么这个新技术有问题，要么一定是姿势不对，走错了路。 因此，准备实施微服务一定要有一个长期的思想准备。不过跨过了最初的门槛之后，剩下的工作可以被复制而且速度会越来越快。 难点2：“架构师精英主义”
很多产品对架构师的依赖很大，即“架构师精英主义”：认为产品架构只有这个组织的“技术精英”——架构师才可以完成，而团队其它成员只需要实现架构师的设计就可以。这是大型企业和大型系统的常见问题，这来源于长期的重量级企业级架构习惯。 而微服务则类似于一种“敏捷边际革命”：即由一个不超过2~8个人的小团队就可以完成的功能。而且这种规模的团队即使从整个产品团队移除也对整体产品的研发进度没有影响。因此，即使失败了不会带来太多的损失。不过，当第一个微服务改造成功，那么成功经验的复制带来的乘数效应却能带来很大的收益。 从架构改造投资的风险收益比来看，这是非常划算的。 因此，微服务团队完全没必要大张旗鼓，只需要两三个人就可以动工。但是，谁也没有微服务的实践经验啊，万一失败了怎么办？ 这就带来了下一个难点。 难点3：缺乏一个信任并鼓励创新的环境
常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③ 以形式化开发方法为基础的变换模型（T ransformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这
前台门户网站高并发架构设 计方案 1 设计思路 为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计: 1)实现web请求的网络负载均衡的设计思路 a)通过硬件实现负载均衡。 b)通过第三方软件来实现负载均衡,同时实现页面请求的缓存。 c)通过web服务器的配置来实现负载均衡 即通过apache将客户请求均衡的分给tomcat1,tomcat2....去处理。 2)WEB应用架构设计思路 a)应用开发实现MVC架构三层架构进行web应用开发 b)采用第三方开源的CMS系统来实现网站内容的管理。 c)页面尽可能静态化以减少动态数据访问。 d)采用页面缓存机制和数据缓存来实现页面请求的缓冲和数据的缓存 3)数据存储的设计思想 a)数据库拆分,把生产数据库和查询数据库分离，对生产数据库采用RAC实现数据库的集 群。 b)采用高效的网络文件共享策略，采用图片服务器来实现页面的图片存储。
2 系统架构设计2.1 网站总体架构 2.1.1 网站的系统架构 1. 分层结构
2. 网络示意图 3. 网站架构设计说明 1)采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载均衡。 2)通过Nigix实现反向代理服务器集群 3)同时搭建squid集群以作为静态页面的缓存。 4)通过1个apache+多个tomcat进行负载均衡配置，来组成web服务器集群。 5)采用独立的图片服务器集群来实现图片资源的存储及WEB请求。 6)采用HDFS来进行文件的共享访问，通过Rsync来实现远程文件同步。 7)在应用开发中采用基于Struts的MVC架构，同时采用缓存技术来提高动态页面的访问。 8)使页面尽可能静态化，引入CMS系统使网站进一步静态化。 9)对数据库采用生产数据库和查询数据库分离，同时采用oracle 的Rac技术来实现集群扩展。 10)通过镜像技术来实现不同网络服务商的接入速度问题。
大型软件开发人员的组织与分工 大型软件项目需要很多人的能力合作，花费一年或数年的时间才能完成。为了提高工作效率，保证工作质量，软件开发人员的组织、分工与管理是一项十分重要和复杂的工作，它直接影响到软件项目的成功与失败。首先，由于软件开以人员的个人素质与差异很大，因此对软件开发人员的选择、分工十分关键。１９７０年，Ｓackman对１２名程序员用两个不同的程序进行试验，结论是：程序排错、调试时间差别为１８：１；程序编制时间差别为１５：１；程序长度庆功别为６：１；程序运行时间差别为１３：１。近年来，随着软件开发方法的提高、工具的改善，上述差异可能会减小，但软件人员的合理选择及分工，充分发挥每个人的特长和经验显然是十分重要的。其次，因为软件产品不易理解、不易维护，因此软件人员的组织方式十分关键。一个重要的原则是，软件开发人员的组织结构与软件项目开发 模式和软件产品的结构相对应，这样可以达到软件开发的方法、工具、与人的统一，从而降低管理系统的复杂性，有利于软件开发过程的管理与质量控制。按树形结构组织软件开发人员是一个比较成功的经验。树的根是软件项目经理和项目总的技术负责人。理想的情况是项目经理和技术负责人由一个 人或一个小组担任。树的结点是程序员小组，为了减少系统的复杂性、便于项目管理，树的结点每层不要超过７个，在此基础上尽量降低树的层数。程序员小组的人数应视任务的大小和完成任务的时间机时定，一般是２～５人。为降低系统开发过程的复杂性，程序员小组之间，小组内程序员之间的任务界面必须清楚并尽量简化。 按“主程序员”组织软件开发小组是一条比较成功的经验。“主程序员”应该是“超级程序员”。其他成员，包括程序员、后备工程师等，是主程序员的助手。主程序员负责规划、协调和审查小组的全部技术活动。程序员负责软件的分析和开发。后备工程师是主程序员的助手，必要时能代替主程序员领导小组的工作并保持工作的连续性。软件开发小组还可以根据任务需要配备有关专业人员，如数据库设计人员、远程通信和协调，提高了工作效率。这种形式的成败主要取决于程序员的技术和管理水平。除了按主程序员负责的程序员小组组织开发人员外，还可以按“无我程序设计”建立软件民主开发小组。这各组织形式强调组内成员人人平等，组内问题均由集体讨论决定。这种组织形式有利于集思广益、互相取长补短，但工作效率比较低。 软件项目或软件开以小组可以配置若干个秘书、软件工具员、测试员、编辑和律师等。秘书负责维护和软件配置中的文档、源代码、数据及所依附的各种磁介质；规范并收集软件开发过程中的数据；规范并收集可重用软件，对它们分类并提供检索机制；协助软件开发小组准备文档，对项目中的各种参数，如代码行、成本、工作进度等，进行估算；参与小组的管理、协调和软件配置的评估。大型软件项目需专门配置一个或几个配置管理人员，专门负责软件项目的程