欢迎朋友，我是一名十多年开发经验的新手，希望多多指教。

在业务系统开发中，日志的收集和分析很重要，特别是在进行故障分析时，日志记录得好，可以帮我们快速定位问题原因。在互联网分布式系统下，日志变得越来越分散，数据规模也越来越大，如何更好地收集和分析日志，就变成了一个特别重要的问题。

在之前的内容中，分析了分布式系统下的线上服务监控的常用指标，那么在实际开发中，如何收集各个监控指标呢？线上出现告警之后，又如何快速处理呢？本文我们就来看下这两个问题。

在分布式高可用设计中，系统监控非常重要，系统监控做好了，可以提前对异常情况进行报警，避免很多线上故障的产生。系统监控做得好不好，也是评价一家互联网公司基础建设水平的重要标准，今天一起来讨论一下，线上服务都有哪些监控指标，又应该如何展开呢？

在分布式系统的高可用设计中，负载均衡非常关键，我们知道，分布式系统的特性之一就是支持快速扩展，那么集群扩展之后，服务请求如何从服务器列表中选择合适的一台呢？这就需要依赖负载均衡策略。

在实际开发中，数据库的扩容和不同的分库分表规则直接相关，今天我们从系统设计的角度，抽象了一个项目开发中出现的业务场景，从数据库设计、路由规则，以及数据迁移方案的角度进行讨论。

之前我们讲到了分库分表，现在考虑这样一个问题：在单库单表时，业务 ID 可以依赖数据库的自增主键实现，现在我们把存储拆分到了多处，如果还是用数据库的自增主键，势必会导致主键重复。那么我们应该如何解决主键问题呢？本文就来看下生成唯一主键相关的知识。

容器技术是近几年计算机领域的热门技术，特别是随着各种云服务的发展，越来越多的服务运行在以 Docker 为代表的容器之内。本文我们就来分享一下容器化技术相关的知识。

分布式事务是分布式系统中非常重要的一部分，最典型的例子是银行转账和扣款，A 和 B 的账户信息在不同的服务器上，A 给 B 转账 100 元，要完成这个操作，需要两个步骤，从 A 的账户上扣款，以及在 B 的账户上增加金额，两个步骤必须全部执行成功；否则如果有一个失败，那么另一个操作也不能执行。分布式事务的经典应用比如转账扣款，下订单扣库存，新会员送积分等等涉及多个业务共同参与在一个请求中。

亿级流量架构服务降级

高性能高负载解决思路

分库分表总结

集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。

数据迁移方案(医疗卫生信息)

硬件服务器虚拟化之XenServer和vSphere介绍

搭建SFTP服务, 提供sftp服务，scp服务，可以精确控制权限。不提供给用户shell，chroot 用户在主目录。用于和外部之间的文件交换，防止安全事件。同时也可以结合sshterm，来实现对文件的操作记录。SFTP目前广泛应用在运营上传下载文件，和银行物流公司等外部实体进行对账文件交换等。

如果您在客户端使用应用程序的过程中 更新目录，则客户端最初可能下载旧代码，然后尝试下载自那时起已经更新的其他代码。这可能导致不可预知的结果，并且可能导致您的应用程序失败。如果您已经使用无接触部署方法部署了简单应用程序或更为复杂的应用程序的组成部分，则通过在 Web 服务器上放置新文件即可更新这些程序集。在应用程序加载程序集之前，NET Framework 会自动在本地以及在 Web 服务器上检查该程序集的时间戳，以便确定是否需要重新下载该程序集，或者是否可以只是从用户的程序集下载缓存中运行该程序集。

对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，“模型”是必须的，而且，表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。建立企业应用系统的情形可以从以上例子得到启发，企业系统要表述的，主要是复杂的结构，过程占的比重很小，因此，模型就变得更加重要乃至必要了。

SOA 是Service Oriented Architecture的缩写，代表了一种软件开发方法。其核心思想是由擅长软件开发的技术人员把一个个的业务功能包装成一个个标准的服务，精通商业流程的专家通过组合这些服务可以很容易的搭建功能完善的企业应用，或者重新组合这些服务成全新的应用以满足企业的不断变化的需求。这里只是给出了SOA简单的介绍后面将会详细的讲述SOA架构。

The Open Group SOA参考架构提供了：　　企业架构的基础，或者蓝图，因此企业架构师可以使用这些模板或者蓝图作为标准，将其实例化到每个开发中的单独项目或者解决方案中。这将在组织中被执行，这也是SOA参考架构将被实施的地方。这一SOA参考架构被设计为支持不同种类的场景，包括牵涉到客户组织、供应商、其它标准实体以及其它开放组织项目等等。

从架构、技术和需求的关系来看。一个软件产品包含了需求和技术，而架构同样是要包括需求和技术的，只是它没有全包全括这个需求和技术，应该是一些整体性的需求，尤其是一些非功能性的需求。如果在构建架构的时候，架构设计人员根本不了解企业使用的目标软件的整体需求，企业使用目标系统的整体环境，那指望架构适用显然有点强求。

根据SaaS应用是否具有可配置性、高性能、可伸缩性的特性，SaaS成熟度模型被分成四级。每一级都比前一级增加以上三种特性的一种。

对于日志管理当前网络上提供了大量的日志工具，今天就给大家分析总结一下这些常用工具的特点，希望对你们在选型时有所帮助，如果有用记得一键三连。

简要说明：该用例允许系统记录所有车辆排放超标导致的报警信息，报警信息包括车辆信息、报警项、报警时间、处理结果。该用例的主要参与者是系统的管理员。它包括网关设备的查询、创建、删除和修改以及网关设备的运行状态和远程开、关。该用例的主要参与者是系统的管理员。该用例的主要参与者是系统的管理员。简要说明：该用例主要展示系统采集车辆的环保信息，以时间为单位（采集评率待定，包含历史信息）。该用例的主要参与者是系统的管理员。简要说明：该用例允许系统管理员管理系统中所有用户的角色，它包括已分配角色用户的角色修改。

设计模式、架构的博客专栏和文章