_iorilan-CSDN博客

随业务演化的架构每项设计决策必须考虑到业务这项设计原则虽然看起来很明显，但在设计解决方案时要牢记这一点。你有数百万的用户，还是几千？一小时服务中断是否可以接受？系统会有大并发，还是流量始终比较小并且是可预测的？最终的每个设计决策都必须由业务需求进行说明。建议做法定义业务目标，包括恢复时间目标（RTO），恢复点目标（RPO）和容许中断的最大值（MTO）。这些数字应该关系到架构的确定。例如，要实现低R

2017-09-17 15:54:32 928

翻译 azure 最佳实践-- 为演化而设计

为演化而设计为演化而设计是持续创新的关键。所有成功的应用程序都在随时间的推移而演变，无论是错误修复，添加新功能，引入新技术，还是提高现有系统的可扩展性和弹性。如果应用程序的所有部分都紧密耦合，则导致系统将很难更改。应用程序的一部分更改可能会影响另一部分，或导致整个代码库大幅度改动。这个问题并不局限于单一应用程序。应用程序可以分解为服务，但仍存在使系统刚性和脆弱的紧耦合。但是当服务而演化而设计时，团

2017-09-17 15:53:14 493

翻译 azure 最佳实践 -- 使用正确的数据存储

使用正确的数据存储选择最佳的数据存储方案并正确使用把所有的数据都放入一个很大的关系型SQL数据库的时代已经过去。关系数据库所擅长做的-为关系数据交易提供ACID保证。但同时也有一些代价：- 查询可能会包含昂贵的联接。- 数据必须被归一化并符合预定义的模式（写入模式）。- 锁可能会影响性能。在大型解决方案中，单一的数据存储技术可能无法满足所有需求。关系数据库的替代方案主要有键/值存储，文档数据库，搜

2017-09-17 15:51:11 869

翻译 azure 最佳实践 -- 尽量使用托管服务

尽量使用托管服务如果可能，使用平台即服务（PaaS）而不是基础架构即服务（IaaS）。IaaS就像有一盒散件。你可以建造任何东西，但必须自己组装。而托管服务更易于配置和管理。您不需要配置VM，设置VNets，管理修补程序和更新，以及运行在VM之上的所有软件相关的开销。例如，假设你的应用程序需要一个消息队列。你可以使用类似RabbitMQ这样的组件在VM上配置自己的消息传递服务。但是Azure服务总

2017-09-17 15:50:14 1248

翻译 azure 最佳实践-- 系统运维

系统运维方案对应用程序进行设计，使运维团队拥有他们需要的工具，云已经大大影响了运维所扮演的角色。他们不再负责管理托管应用程序的硬件以及基础架构。然而，运维仍然在运行成功云应用程序中扮演着关键角色。运维团队的一些重要职能包括：部署监控系统升级对异常的响应安全审计完整的日志和跟踪追踪机制在云应用中尤为重要。需要运维团队参与设计，以确保应用程序为他们提供需要有帮助的数据和见解。建议做法使一切都是可监控的

2017-09-17 15:48:17 865

翻译 (翻译)terry crowley：写给程序员

(翻译)terry crowley：写给程序员

2017-09-17 15:43:01 943 1

原创 asp.net Webapi登录azureAD并调用azure graph api

asp.net Webapi登录azureAD并调用azure graph api

2017-08-27 21:51:30 2318

翻译 azure 最佳实践5--使用分区

使用分区解决限制使用分区来解决数据库，网络和计算的限制。在云中，所有服务的扩展能力都有限制。Azure服务的具体限制记录在Azure订阅和服务限制，配额和约束中包括核数量，数据库大小，查询和网络流量吞吐量。如果你的系统增长到足够大，就可能会遇到这些限制中的一个或多个。可使用分区来解决这些限制。有很多方法来对系统进行分区：分区数据库以解决数据库大小、I/O或并发会话数量的限制。对队列或消息总线分区，

2017-08-27 21:45:50 637

翻译 azure 最佳实践4 --可水平扩展的设计

可水平扩展的设计设计您的应用程序，使其可以水平扩展。云的主要优点是系统可根据需要可伸缩 - 容量的大小随需求可变，系统随负载的增加可水平扩展，并且在不需要时进行收缩。对应用程序进行设计，使其可以根据需要进行水平伸缩。推荐做法避免粘（有状态）实例。粘性或会话关联性是指，当来自同一客户端的请求总是（需要）被路由到相同的服务器。粘性限制了应用程序的扩展能力。例如，大并发的流量不会将压力均发到实例上。粘性

2017-08-27 21:42:12 459

翻译 azure 最佳实践 3--最小协同操作

最小化协同操作最小化应用服务之间的协同，提高可扩展性。大多数云应用程序包含多个服务 - Web前端，数据库，业务，报表以及高级分析等等。为了可扩展性和可靠性，这些服务应该在多个实例上运行。当两个实例尝试执行影响某些共享状态的并发操作时会发生什么？在某些情况下，例如，为了保持ACID原则就必须在节点之间进行协同操作。在下图中，节点2正在等待节点1释放数据库锁：协同限制了水平扩展并制造了瓶颈。在此示例

2017-08-27 21:39:59 546

原创 Linux setup kafka

.make sure ubuntu is updated sudo apt-get update -ysudo apt-get upgrade -y.install javasudo add-apt-repository -y ppa:webupd8team/javasudo apt-get updatesudo apt-get install oracle-java8-instal

2017-08-27 21:24:21 556

原创 python 3 登录azureAD并调用azure graph api

python 3 登录azureAD并调用azure graph api

2017-08-27 21:22:09 1385

原创 linux 更新nodejs到最新

linux 更新nodejs到最新

2017-08-27 21:17:44 3285

原创 Swift 3 popup model dialog传递数据

Swift 3 popup model dialog传递数据

2017-08-27 21:13:08 730

原创 swift3 键盘通知事件

swift3 键盘通知事件

2017-08-27 21:11:54 724

原创 Swift 3 打印功能

Swift 3 打印功能

2017-08-27 21:10:21 839

翻译 azure 最佳实践 -- 保持冗余

保持冗余确保你的应用的部署体系是有冗余的，以避免单一节点失败的情况。一个弹性良好的系统可以灵活的绕过系统故障。找出应用中（请求执行）的关键路径。路径中的每个节点是否都有冗余？子系统失败时，系统能否有效的转移故障？也要考虑到业务需求。每个（节点的）冗余都会导致额外的开销和复杂度。你的架构应该考虑到业务需求的标准，例如，目标恢复时间（Recovery time objective）。再如，多区域部署肯

2017-07-30 13:30:04 937

翻译 azure最佳实践系列1-自我修复的设计

如何设计你的应用，能够在系统错误时做到自我修复？在分布式系统中，会经常遇到错误。硬件也会遇到异常情况。网络有时会出现短暂的错误。整个地区出现了服务中断。即便如此，关于这些问题的方案也是要提前规划的。因此，需要设计一个能够在错误出现时完成自我修复的系统，主要包括以下3个部分：发现错误。正确的对待错误。使用日志并监控错误，提高可操控性。对故障类型的响应取决于应用的可用性的需求。例如，如果你需要系统是高

2017-07-28 00:07:29 502