关于php 高并发解决的一点思路

涉及抢购、秒杀、抽奖、抢票等活动时,为了避免超卖,那么库存数量是有限的,但是如果同时下单人数超过了库存数量,就会导致商品超卖问题。那么我们怎么来解决这个问题呢,我的思路如下(伪代码):

sql1:查询商品库存
if(库存数量 > 0)
{
//生成订单…
sql2:同时库存-1
}

当没有并发时,上面的流程看起来是再正常不过了,假设同时两个人下单,而库存只有1个了,在sql1阶段两个人查询到的库存都是>0的,于是最终都执行了sql2,库存最后变为-1,超售了,这不是我们想要的结果吧。

解决这个问题比较流行的思路我总结了下:
1.用额外的单进程处理一个队列,下单请求放到队列里,一个个处理,就不会有并发的问题了,但是要额外的开启后台进程以及延迟问题,这里暂不予考虑。这里我可使用消息队列,我们常用到Memcacheq、Radis。 比如:有100张票可供用户抢,那么就可以把这100张票放到缓存中,读写时不要加锁。 当并发量大的时候,可能有500人左右抢票成功,这样对于500后面的请求可以直接转到活动结束的静态页面。进去的500个人中有400个人是不可能获得商品的。所以可以根据进入队列的先后顺序只能前100个人购买成功。后面400个人就直接转到活动结束页面。当然进去500个人只是举个例子,至于多少可以自己调整。而活动结束页面一定要用静态页面,不要用数据库。这样就减轻了数据库的压力。
2.mysql乐观锁,意思是比如总库存是2,抢购事件提交时,立马将库存+1,那么此时库存是3,然后订单生成后,在更新库存前再查询一次库存(因为订单生成理所当然库存-1,但是先不急,再查一次库存返回结果是3),看看跟预期的库存数量(这里预期的库存是3)是否保持一致,不一致就回滚,提示用户库存不足。这里说道悲观锁,可能有朋友会问,那一定有乐观锁了吧??这里我就浅谈下我所了解的悲观与乐观锁了

悲观锁与乐观锁是两种常见的资源并发锁设计思路,也是并发编程中一个非常基础的概念。本文将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍。

悲观锁(Pessimistic Lock)


悲观锁的特点是先获取锁,再进行业务操作,即“悲观”的认为获取锁是非常有可能失败的,因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持,即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁,因此其他并发执行的select for update如果试图选中同一行则会发生排斥(需要等待行锁被释放),因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放,因此必须在事务中使用。

这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的,例如oracle支持select for update no wait,表示如果拿不到锁立刻报错,而不是等待,mysql就没有no wait这个选项。另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上,这一点很容易造成问题。因此如果在mysql中用悲观锁务必要确定走了索引,而不是全表扫描。

乐观锁(Optimistic Lock)


乐观锁的特点先进行业务操作,不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的,因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。

乐观锁在数据库上的实现完全是逻辑的,不需要数据库提供特殊的支持。一般的做法是在需要锁的数据上增加一个版本号,或者时间戳,然后按照如下方式实现:

复制代码
1. SELECT data AS old_data, version AS old_version FROM …;
2. 根据获取的数据进行业务操作,得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
    // 乐观锁获取成功,操作完成
} else {
    // 乐观锁获取失败,回滚并重试
}
复制代码

乐观锁是否在事务中其实都是无所谓的,其底层机制是这样:在数据库内部update同一行的时候是不允许并发的,即数据库每次执行一条update语句时会获取被update行的写锁,直到这一行被成功更新后才释放。因此在业务操作进行前获取需要锁的数据的当前版本号,然后实际更新数据时再次对比版本号确认与之前获取的相同,并更新版本号,即可确认这之间没有发生并发的修改。如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了,此时认为获取锁失败,需要回滚整个业务操作并可根据需要重试整个过程。好吧,在此唠叨总结下这两个锁:

总结

  • 乐观锁在不发生取锁失败的情况下开销比悲观锁小,但是一旦发生失败回滚开销则比较大,因此适合用在取锁失败概率比较小的场景,可以提升系统并发性能
  • 乐观锁还适用于一些比较特殊的场景,例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方

3.根据update结果来判断,我们可以在sql2的时候加一个判断条件update table set 库存=xxx where 库存>0,如果返回false,则说明库存不足,并回滚事务。
4.借助文件排他锁,在处理下单请求的时候,用flock锁定一个文件,如果锁定失败说明有其他订单正在处理,此时要么等待要么直接提示用户”服务器繁忙”

大致代码如下:
阻塞(等待)模式

复制代码
<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX))   //锁定当前指针,,,
{
  //..处理订单
  flock($fp,LOCK_UN);
}
fclose($fp);
?>
复制代码

非阻塞模式

复制代码
<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX | LOCK_NB))
{
  //..处理订单
  flock($fp,LOCK_UN);
}
else
{
  echo "系统繁忙,请稍后再试";
}
 
fclose($fp);
?>
复制代码

5.如果是分布式集群服务器,就需要一个或多个队列服务器 小米和淘宝的抢购还是有稍许不同的,小米重在抢的那瞬间,抢到了名额,就是你的,你就可以下单结算。而淘宝则重在付款的时候的过滤,做了多层过滤,比如要卖10件商品,他会让大于10的用户抢到,在付款的时候再进行并发过滤,一层层的减少一瞬间的并发量。

6.使用redis锁 product_lock_key 为票锁key 当product_key存在于redis中时,所有用户都可以进入下单流程。 当进入支付流程时,首先往redis存放sadd(product_lock_key, “1″),如果返回成功,进入支付流程。如果不成,则说明已经有人进入支付流程,则线程等待N秒,递归执行sadd操作。

当然类似于淘宝双11的疯抢架构远远比我说滴这些复杂多啦….更多解决方案需要不停滴去实战中获取心得….大家有好的解决思路清随时共享留言哈

 

无论从事什么行业,只要做好两件事就够了,一个是你的专业、一个是你的人品,专业决定了你的存在,人品决定了你的人脉,剩下的就是坚持,用善良專業和真诚赢取更多的信任。不忘初心 方得始终!

Charles 手机抓包连接教程,亲身试过

最近使用Charles抓包,在网上搜教程,很多教程都不完整,弄了好久才弄好连接手机抓包功能,这次自己整理一下,分享出来,也便于以后自己使用,下面开始吧。

1、     安装Charles

破解安装包地址:http://pan.baidu.com/s/1kUUj2gn

包含证书和破解jar包

2、安装好,Charles之后,进行配置,要确保在一个wifi

环境中,使用ifconfig en0查看电脑连接wifi所用的ip:

或者在打开网络偏好设置中,查看电脑的ip地址:

3、打开CharlesProxy->Proxy Settings,选中Enabel transparent HTTPproxying。点击ok。Port一般都是8888,这个要和下一步手机中的端口相同。

4、打开手机,设置->无线局域网下的HTTP代理,选择手动:

5、点击返回,电脑中Charles会出现一个提示框,点击allow。

如果没有出现点击Proxy->Access control settings,添加你的手机ip。

6、现在我们用我们的iPhone打开 safari中输入这个网址,安装描述文件。

IOS9输入:

https://www.charlesproxy.com/getssl

其他:

http://www.charlesproxy.com/getssl

注:IOS9开始使用https

下载描述文件安装。

如果提示连接网络失败关闭电脑wifi重新打开一次,并重启Charles就可以了。

Announcing .NET Core 1.1

We are excited to announce the release of .NET Core 1.1 RTM, the first “Current” release. You can start creating .NET Core 1.1 apps, today, in Visual Studio 2015, Visual Studio 2017 RC, Visual Studio Code and Visual Studio for the Mac.

We used the 1.1 release to achieve the following improvements:

  • .NET Core: Add distros and improve performance.
  • ASP.NET Core: Improve Kestrel, Azure support and productivity.
  • EF Core: Azure and SQL 2016 support.

News flash: ASP.NET Core 1.1 with Kestrel was ranked as the fastest mainstream fullstack web framework in the TechEmpower plaintext benchmark.

News flash: Google Cloud is joining the .NET Foundation Technical Steering Group. Welcome, Google!

You can see all the .NET Core changes in detail in the .NET Core 1.1 release notes. It’s a small delta on the .NET Core 1.1 Preview 1 release that we shipped 3 weeks ago.

Installing

You can install the new release from the .NET Core downloads page. .NET Core is a Current release. Make sure to click the “Current” button to see the .NET Core 1.1 download links.

Distributions

Support for the following distributions was added:

  • Linux Mint 18
  • OpenSUSE 42.1
  • macOS 10.12 (also added to .NET Core 1.0)
  • Windows Server 2016 (also added to .NET Core 1.0)

You can see the full list of supported distributions in the .NET Core 1.1 release notes.

Documentation

.NET Core documentation has been updated for the release and will continue to be updated. We are also in the process of making visual and content updates to the .NET Core docs to make the docs easier and more compelling to use.

The ASP.NET Core and Entity Framework, C# and VB docs were moved to docs.microsoft.com as part of this release. F# documentation was added a few months ago.

Documentation on docs.microsoft.com open source. You can help us make it better by filing issues and making contributions on GitHub. Best places to start are dotnet/docs and aspnet/docs.

Performance

We were recently informed by the fine folks at TechEmpower that ASP.NET Core 1.1 with Kestrel was ranked as the fastest mainstream fullstack web framework in the TechEmpower plaintext benchmark. That’s a great result, and the result of significant engineering effort.

We adopted a performance optimization for the CoreCLR runtime called Profile-Guided Optimization (PGO), for the .NET Core 1.1 Windows version. We’ve use this technique for the .NET Framework for many years, but had not yet used it for .NET Core. This improvement was not included in the earlier .NET Core 1.1 Preview 1 release.

PGO optimizes C++ compiler-generated binaries with information it records from apps it observes in our lab. We call this process “training”. It’s about as exciting as 6AM runs in the dark during the Winter. PGO records info about which codepaths are used in a binary and in what order. For this release, we used a simple “Hello World” app for training.

We saw a 15% improvement with the ASP.NET MusicStore app running with a PGO-optized CoreCLR in our lab and believe that these improvements will be representative to other Web applications. We hope to see greater improvements in the future as we increase the pool of apps we train with.

For Linux and macOS, we compile CoreCLR with Clang/LLVM. We intend to use the Clang version of PGO in the next release. Very preliminary scouting of Clang PGO suggests that we will see similar benefits.

APIs

There are 1380 new APIs in .NET Core 1.1. Many of the new APIs were added to support the product itself, include reading portable PDBs. .NET Core 1.1 supports .NET Standard 1.6.

.NET Standard 2.0 support is coming in an upcoming release (in 2017). It is not part of .NET Core 1.1.

Using .NET Core 1.1

You can start by installing .NET Core 1.1. You can either install it globally using the .NET Core 1.1 installer or package manager for your operating system or try it an isolated (and easily removable) environment by downloading .NET Core as a zip.

Safe side-by-side install

You can safely globally install .NET Core 1.1 on a machine that already has .NET Core 1.0.

The dotnet new command creates new templates that reference the latest runtime on the machine. This may not be desired. If not, you can hand-edit the versions in the resulting project.json to earlier version numbers. Based on feedback, we will be changing this behavior in the new version of the tools, at the same time we release the final version of Visual Studio 2017. If you do not use dotnet new to create new projects, but rely on Visual Studio, then you are not affected.

Try it out

You can try .NET Core out with the command line tools, using these commands in your command prompt or terminal.

dotnet new
dotnet restore
dotnet run

You can also try out .NET Core 1.1 with a dotnet-bot sample we created for using .NET Core with Docker (although you don’t have to use Docker).

Upgrading Existing .NET Core 1.0 Projects

You can upgrade existing .NET Core 1.0 projects to .NET Core 1.1. I will show you the new project.json file that the updated dotnet new now produces. It’s the best way to see the new version values that you need to copy/paste into your existing project.json files. There are no automated tools to upgrade projects to later .NET Core versions.

The default .NET Core 1.1 project.json file follows:

{
version: 1.0.0-*,
buildOptions: {
debugType: portable,
emitEntryPoint: true
},
dependencies: {},
frameworks: {
netcoreapp1.1: {
dependencies: {
Microsoft.NETCore.App: {
type: platform,
version: 1.1.0
}
},
imports: dnxcore50
}
}
}
view rawproject.json hosted with ❤ by GitHub

This project.json file is very similar to what your .NET Core 1.0 project.json looks like, with the exception of the netcoreapp1.1 and 1.1.0target framework and meta-package version strings, respectively.

You can use the following substitutions to help you update project.json files that you want to move temporarily or permanently to .NET Core 1.1.

  • Update the netcoreapp1.0 target framework to netcoreapp1.1.
  • Update the Microsoft.NETCore.App package version from 1.0.x (for example, 1.0.0 or 1.0.1) to 1.1.0.

Upgrading .NET Standard Library Projects

There is no need to update .NET Standard Library projects.

We did publish a NETStandard.Library 1.6.1 meta package, however, there is no benefit in referencing it for producing libraries. The updated package has been provided as a dependency for the updated Microsoft.NETCore.App 1.1 metapackage.

Using .NET Core 1.1 Docker Images

You can use .NET Core 1.1 with Docker. You can find updated images at microsoft/dotnet.

The latest tag has been updated to point to the .NET Core 1.1 SDK. This is a departure from our earlier plan, as discussed in the 1.1 Preview 1 post. We looked at other platforms that have Current and LTS and saw that latest does indeed point to the latest version. Makes sense.

There are two new Runtime tags for .NET Core 1.1:

  • Linux: 1.1.0-runtime
  • Windows: 1.1.0-runtime-nanoserver

There are two new SDK tags for .NET Core 1.1:

  • Preview 2-based SDK, using project.json: 1.1.0-sdk-projectjson
  • Preview 3-based SDK, using CSProj: 1.1.0-sdk-msbuild, .

You can try .NET Core 1.1 with the [dotnetapp-current sample][dotnetapp-current] in the .NET Core Docker Samples repository. The other samples can be easily modified to also depend the .NET Core 1.1 images, by updating both the project.json and Dockerfile files with the appropriate version strings (all of which are provided above).

Current Release

In the earlier .NET Core 1.1 blog post, I described that we have adopted the industry practice of differentiated releases, which we’ve called “Long-term Support (LTS)” and “Current”. .NET Core 1.1 is a Current release and also the first one. Once a given Current release has shipped, we expect very few updates, hopefully only security updates.

We recommend that most developers adopt LTS releases. It’s also the default experience we’ll include in Visual Studio. We do hope that some of you adopt Current releases to give us feedback, as well. It’s hard to quantify it, but we thinking an 80/20 split between LTS and Current across the entire .NET Core developer base would be about right.

Closing

Please try the new .NET Core release and give us feedback. There are a lot of key improvements across .NET Core 1.1, ASP.NET Core and EF Core that will make your apps better and faster. It’s the first Current release, providing you with feature faster, provided you are happy with updating .NET Core more quickly than the LTS multi-year supported releases.

To recap, the biggest changes are:

  • Performance improvements, enough to make a very positive first entry on the TechEmpower benchmarks.
  • Addition of four OS distros.
  • 10s of new features and 100s of bug fixes.
  • Updated documentation.

Thanks to everyone who adopted .NET Core 1.0 and .NET Core 1.1 Preview 1 that gave us feedback. We appreciate all of the contribution and engagement! Please tell us what you think of the latest release.

You can start creating .NET Core 1.1 apps, today, in Visual Studio 2015, Visual Studio 2017 RC, Visual Studio Code and Visual Studio for the Mac.

.NET 应用迁移到 .NET Core:调查案例

上周已经发过三篇文章讲述做.NET 应用迁移到.NET Core的一般方法,具体内容请看:

.NET应用迁移到.NET Core(一)

.NET应用迁移到.NET Core(二)风险评估

.NET应用迁移到.NET Core(三)从商业角度看移植过程

今天给大家展示一个真实的项目的调查案例,一个轻量级的.NET 工作流引擎移植到.NET Core平台的调查案例,你也可以参照这篇案例进行迁移前的项目调查工作。

该调查问卷可以作为移植技术的一个指南,并且据此还可以提出其他一些问题。该问卷中的客户指的是一个要移植到 .NET Core 的内部或外部部门。

1、 你当前的应用程序开发平台是什么?

该问题是关于开发待移植 .NET 应用程序的开发平台。这里不假设开发平台和应用程序部署的平台是相同的。这留在下一个问题中。

Windows 7 + IIS 7.5 + .NET Framework 4.5 +Redis 2.4 + SQL Server 2008 R2

2、 该应用程序当前运行的平台是什么?

移植工程师需要知道待移植的应用程序当前运行的平台。

Windows 2008 R2 SP1 + IIS 7.5 + .NETFramework 4.5 + Redis 2.4 + SQL Server 2008 R2

3、 除了开发平台外,该应用程序是否还在其他平台上部署过?如果部署过,它运行的平台版本是什么 ?

问此问题可以让你知道应用程序的可移植性,看它是否移植到其他平台上。不过有一点需要注意:即使应用程序曾移植到其他平台上,它的目标平台可能也是比较老的版本。

没有在其他平台部署过。

4、 描述应用程序使用的系统信息,以及需要的驱动程序在 Linux 平台上是否可用。

确定 Linux 能够满足应用程序对平台的依赖。

系统信息:

  • .NET Framework 对应的 Linux 平台上有 Mono 和 .NET Core 两大平台

  • Redis 已经是在 Linux 平台上运行

  • Web 服务器 IIS 对应 Linux 平台上有 Jexus(Mono) 和 Apache/Nginx + Kestrel

  • SQL Server 在 Linux 平台上存在但是还是预览版,可以迁移到 MySQL

  • Entity Framework 6.1 和 Entity Framework Core 本身就是跨平台的,支持在 Linux 平台上访问 SQL Server

  • ServiceStack.Redis 也是支持 Mono 和 .NET Core

  • Owin 服务器在 Linux 平台上有 Jexus 支持 和 .NET Core 的支持

  • ASP.NET Web API 2.2 Linux 平台上有 Mono 4.6 支持,也可以迁移到 .NET Core

  • Windows 服务可以迁移到 Linux 的后台服务,可以 Topshelf 改造或者是迁移到 .NET Core 控制台应用,使用 Linux 系统服务或者是 Supervisorctl 运行

  • 站点使用的 ASP.Net MVC 在 Linux 上 Mono 4.6 支持,或者迁移到 .NET Core

1、 请详细描述应用程序及其结构。

在这里,用户可以描述应用程序的结构,并尽可能地包括结构图。应用程序的所有组件都要描述。如果有的话,该问题也应该会让你知道应用程序运行的框架。大部分的 .NET 应用程序运行在产品相关的框架上,例如 IIS 、 windows 服务和 WCF 服务。也就是说,需要你处理 .NET Core 可能不支持的某个具体的框架。

HRCommFlow 应用包括 2 部分:对外的 API 服务 和 Web 站点。

对外服务的 API 服务使用 ASP.NETWeb API ,使用 Windows 服务自宿主。使用的组件如下:

应用框架 组件 备注
ASP.NET Web API System.Web.Http
System.Web.Http.Owin
Microsoft.Owin.Host.HttpListener
EntityFramework 访问 SQL Server
Newtonsoft.Json Json
ServiceStack.Redis 访问 Redis
Tencent.OA.Framework 访问组织机构信息
ExpressionEvaluator
System.ServiceProcess

Web 站点使用 ASP.NET MVC 4 , 使用 IIS 宿主

应用框架 组件 备注
ASP.NET MVC Microsoft.AspNet.Mvc
Microsoft.AspNet.Razor
EntityFramework 访问 SQL Server
Newtonsoft.Json Json
Tencent.OA.Framework 访问组织机构信息
ExpressionEvaluator
System.ServiceProcess

2、 该应用程序有哪些不同组件?请给出各组件的名称和版本号。

该问题让你细分应用程序的结构,把应用程序细分成不同的组件。也就是说,可以把整个移植工作分成多个独立的任务。

组件名称 版本号 是否公开源代码
System.Web.Http 4.0.0.0
System.Web.Http.Owin 5.2.3.0
Microsoft.Owin.Host.HttpListener 3.0.0.0
EntityFramework 6.1.3
Newtonsoft.Json 6.0.8
ServiceStack.Redis 3.9.71.0
Tencent.OA.Framework 1.0.0.0
ExpressionEvaluator 2.0.4.0
System.ServiceProcess 4.0.0.0
Microsoft.AspNet.Mvc 4.0.30506.0
Microsoft.AspNet.Razor 2.0.30506.0

3、 那些组件需要移植,那些不需要?请包含版本号。

客户需要告诉你那些需要移植,那些不需要。

组件名称 版本号 移植到 Mono 移植到 .NET Core
System.Web.Http 4.0.0.0 不需要 不需要
System.Web.Http.Owin 5.2.3.0 不需要 不需要
Microsoft.Owin.Host.HttpListener 3.0.0.0 不需要 不需要
EntityFramework 6.1.3 不需要 不需要
Newtonsoft.Json 6.0.8 不需要 不需要
ServiceStack.Redis 3.9.71.0 不需要 不需要
Tencent.OA.Framework 1.0.0.0 需要 需要
ExpressionEvaluator 2.0.4.0 需要 需要
System.ServiceProcess 4.0.0.0 不需要 不需要
Microsoft.AspNet.Mvc 4.0.30506.0 不需要 不需要
Microsoft.AspNet.Razor 2.0.30506.0 不需要 不需要

4、 待移植的应用百分之多少是用下列编程语言编写 ?

  • Java

  • C#

  • F#

  • C

  • C++

  • 汇编语言

  • Visual Basic

  • IronPython/IronRuby

  • Powershell

通过询问应用程序使用了什么语言及其所占的比重,来确定应用程序的复杂度。

100% 使用 C# 语言编写

5、 粗略估计一下各语言所占的代码行数。

这是对问题 4 的另外一种问法,从不同的角度提出问题,常常能找到互相矛盾的地方,这就需要公开讨论,从而能够把项目调查清楚。

代码数量大概是 3500 行。

6、 对于 .NET 应用程序:使用了 P/Invoke 来链接特有的库了吗?请描述之。

明确待移植的应用程序的复杂度。多数情况下,非 100% 纯 .NET 编写的应用程序,都需要平台相关的例程,这些例程只能用固有的语言来处理,例如 C 语言。请注意这些平台相关的代码,往往它需要花费较多的时间来移植。

没有

7、 应用程序用了操作系统内核模块了吗?如果有,请描述之。

明确待移植的应用程序的复杂度。如果应用程序使用的操作系统内核模块和例程是不可移植的,就需要花费较多时间转换成目标平台上对应的例程。

没有

8、 该应用程序是 2D/3D 的图形应用程序吗?请描述之。

明确待移植的应用程序的复杂度。确认 .NET Core 上存在兼容的图形工具和开发工具,无论是系统默认提供的或者是第三方发行商提供的。

没有

9、 应用程序使用了消息队列、共享内存、信号或者信号量吗?请描述之。

上述内容大部分能够方便的移植到 .NET Core 上。需要确认移植到 .NET Core 后,能够使原来期望的行为。

没有

10、 应用程序或其中的组件,是多线程的吗?如果是,使用的是那种线程库 ? 应用程序依赖开发平台特有的线程属性吗?

Linux 支持多种线程库,但是现在以及将来的 Linux 发行版中,符合标准的线程库是 NPTL ( Native Posix Threads Library )实现。

组件没有多线程,也没有依赖开发平台特有的线程属性。

11、 应用程序的某些操作提前假设某种特定的字节顺序吗?这在移植过程会成为问题吗?

该问题是关于应用程序的 “ 大小端 ” ( Littleendian , Big endian )问题。大部分 .NET 移植到 .NET Core 的目标平台都是 Intel 平台,该平台是小端的。也有可能要把 .NET 程序移植到 RISC 类的大端平台。假设具体的大小端代码是不可移植的,并且如果移植不正确会导致不易察觉的错误。更糟糕的是,这些错误在移植时不会暴露出来,只会在系统测试的时候会突然出现问题,并且很难找到问题的根源。

没有假设字节顺序问题, .NET Framework 帮助我们解决这个问题

12、 开发平台使用的是那种编译器版本?

  • C# ( 什么版本? )

  • VB.NET( 什么版本? )

  • F#( 什么版本? )

  • 平台特有编译器( Visual C++ )

  • 其他(请列出)

明确待移植的应用程序的复杂度。如果待移植的应用程序用的是 C#/VB.NET 或者 F# 编译器,则移植到 Linux 上会简单一些,因为 .NET Core 和 .NET 使用相同的编译器。如果用了 windows 平台特有编译器编译的应用程序, C++ 应用程序比 C 程序较难移植,应用程序可能使用了 C++ 特性,例如模板。因为 C++ 标准在不同厂商的编译器上实现不同,移植这种类型的代码比简单的 C/C++ 代码要花费更多的时间。

使用 C# 编写的应用程序, .NET Core 和 .NET 使用相同的编译器, Mono 也是兼容的编译器。

13、 除了开发环境,应用程序还依赖其他的调试工具吗?例如内存泄漏调试器、性能分析工具、异常处理等。

这又回到了调查和分析依赖关系。 Linux 上可能有,也可能没有所需的第三方工具,这需要调查。谁提供许可?谁负责获取这些工具?如果需要第三方支持,谁来提供支持?

没有依赖其他的调试工具。

14、 该应用程序是基于 Socket 的吗?如果是,它使用了 RPC 吗?请描述之。

虽然 Linux 支持标准的 socket 和 RPC 语义,但该问题的目的是确认程序的可移植性,比如 .NET 使用了 WCF 的 RPC , .NET Core 仅支持 WCF 的客户端访问,对于系统移植就很困难。问该问题可以搞清楚客户是否在应用程序里实现了不可移植的结构。该问题也可以引出其他问题,例如在测试阶段需要怎么样的配置。

没有使用 RPC ,使用的是 HTTP Web API ,依赖的组件 Tencent.OA.Framework 依赖于 WCF的客户端访问,需要移植到 HTTP Web API 接口访问。

15、 应用程序使用了第三方软件组件吗(数据库工具、应用程序服务器或其他中间件)?如果是,使用了哪些组件?

每一个第三方软件组件都会增加移植的复杂度。如果使用了任何第三方组件,都需要询问试了该组件的那个版本以及 .NET Core 上是否存在对应版本。第三方组件可能需要额外的时间去学习,甚至是配置或编译。

应用程序使用了第三方组件,

组件名称 版本号 Mono 是否存在对应版本 .NET Core 是否存在对应版本
System.Web.Http 4.0.0.0 存在 存在
System.Web.Http.Owin 5.2.3.0 存在 不存在
Microsoft.Owin.Host.HttpListener 3.0.0.0 存在 不存在
EntityFramework 6.1.3 存在 存在
Newtonsoft.Json 6.0.8 存在 存在
ServiceStack.Redis 3.9.71.0 存在 存在
Tencent.OA.Framework 1.0.0.0 存在 不存在
ExpressionEvaluator 2.0.4.0 存在 不存在
System.ServiceProcess 4.0.0.0 存在 存在
Microsoft.AspNet.Mvc 4.0.30506.0 存在 存在
Microsoft.AspNet.Razor 2.0.30506.0 存在 存在

16、 应用程序时如何交付和安装的?使用标准的打包工具吗?安装脚本也需要移植吗?

Linux 上一个标准的打包工具是 RPM 。 RPM 会在其他章节讲述。明确客户是否需要移植应用程序打包部分的内容。

使用 XPlat 模式,没有使用打包工具,直接拷贝,部署运行。

17、 应用程序或组件是 64 位的吗?有组件需要移植成 64 位的吗?

随着 64 位平台和操作系统的普及,该问题是要知道应用程序需要运行在什么体系结构的平台上。通过现代的编译器,大部分 32 为应用程序都可以轻松移植到 64 位环境上。需要考虑的一点就是移植和调试可能需要较长的时间。

应用程序都是 64 位的,不存在组件需要移植成 64 位。

1、 应用程序当前支持什么数据库?请包括版本号。

现在几乎所有的企业应用程序都需要后台数据库。确认应用程序所需的数据库在 Linux 上可用非常重要。数据库产品以及版本之间的差别会导致增加很多移植工作。

应用程序支持的 SQLServer 2008 R2 ,目前在 Linux 上处于预览版,需要移植到 MySQL 。

2、 移植后的应用程序期望运行在什么数据库上?

除了问题 1 外,客户希望移植后的应用程序运行在 Linux 平台的什么数据库上?

希望移植后应用程序运行在 Linux 的 MySQL 5.6 上。

3、 应用程序使用了非关系数据库或私有数据库吗?

现在还有很多应用程序使用 NoSQL 数据库,幸运的是大部分 NoSQL 数据库都运行在 Linux 上。任何私有数据库都需要移植到 Linux 上。确认运行数据库的代码在 Linux 上可用,这也是调查阶段工作的一部分。

应用程序使用了 NoSQL 数据库 Redis , Redis 在 Linux 上运行良好。

4、 应用程序是如何与数据库通信的?

  • 编程语言(例如 C#,VB.NET 等)

  • 数据库接口(例如 ODBC , ADO.NET , Entity Framework )

确认所用的编程语言或接口在 Linux 上可用,确认是否由第三方厂商提供。

应用程序使用了 Entity Framework 访问 SQL Server ,微软官方提供。

5、 应用程序需要使用扩展的数据类型吗( XML 、 audio , binary 、 video )?

这个问题主要用来评估移植小组需要具备的技能。

应用程序使用 Json 数据类型。

1、 应用程序在目标平台上的正式可用日期是那天?

该问题是要明确在制定移植进度计划时,是否有商业目标需要考虑。

需要在 2017 年春节前上线运营。

2、 应用程序在目标平台上的移植工作已经开始了吗?

这可以帮助评估在正式开始之前发现的复杂度问题。

没有开始。

3、 估计得移植复杂度是什么(低、中还是高)?

需要仔细分析对该问题的回答。现在很可能有一些新的因素在以前的移植经历中没有完全认识到。

移植复杂度适中,都是用 C# 语言编写的应用组件,需要移植的第三方组件也比较少,而且都有源代码。

4、 在确定复杂度级别时,考虑了什么因素?

以前移植工作的任何信息都需要评估,并且与将来的 Linux 平台移植工作进行对比。

5、 该应用程序曾移植到其他平台上吗?用了多长时间?需要多少资源?遇到过什么问题?

该问题试图把以前的移植工作和 .NETCore 移植进行比较。这只有在移植工程师的技术领导同时具有 Windows 平台和 Linux 平台移植经验的情况下,才会有用。

没有

6、 你是怎样粗略估计项目移植时间和所需资源的?

应用程序或某些部分可能曾移植到其他平台上,知道向那些平台移植所花的时间会有些帮助。从那些移植过程得出的经验和教训会派上用场。吸取这些教训可以帮助你避免向 .NET Core 移植时重蹈覆辙。

1、 请描述接收测试的环境配置。

服务器配置 用途 环境
tLinux 2.2/CentOS 7.2 API 服务器 Mono 4.6/Jexus/.NET Core 1.1/Nginx
tLinux 2.2/CentOS 7.2 数据库服务器 MySql 5.6+
tLinux 2.2/CentOS 7.2 Redis 服务器 Redis 3.2
Windows Server 2008 R2 原 API 服务器 / 数据库服务器 SQL Server 2008R2

2、 单元测试需要什么样的网络和数据库配置?

3、 移植测试需要多少时间和资源?

4、 是否已经建立了测试脚本和性能度量标准?

5、 需要运行一些基准测试来进行比较吗?

6、 性能数据在当前平台上可用吗?

7、 最后执行性能测试是什么时间?

所有测试相关的问题都适用于软件程序在 Linux 平台上的测试。问这些问题还可以引出其他一些与移植测试脚本和测试工具有关的问题,而这些可能会增加整个项目的风险和时间。要重点关注客户对问题 1 的回答。问题 1 和接收标准有关,这些标准需要各方在移植开始之前都同意。一个接收标准的例子是:模块 A 和 B 应该通过测试用例 c 和 d ,并且没有错误。当达到测试标准后,移植可以说是完成了,正式的 QA 测试接着就可以开始了。

1、 根据你希望的情况,请选择下面的一项或多项:

  • 必要的话,将会给移植工程师提供一些技术帮助。

  • 客户负责获取第三方工具许可和技术支持。

  • 其他(请描述)。

可以在这里增加你认为需要客户考虑的其他事项。有些问题可能是关于员工培训或测试应用程序等。

2、 项目需要什么硬件?

该问题是要确认是否会用到现有的硬件或额外的硬件,以用于移植、测试、培训,以及必要的支持等。

尽管上述问卷已经比较全面,但是它不应该是调查所依赖的唯一基础。调查还应该包括对应用程序源代码的实际检查。软件程序的文档也需要检查,以便用户能够从中了解到需要的应用程序信息。

.NET社区新闻,深度好文,微信中搜索 dotNET跨平台 或扫描二维码关注

.NET 4.5+项目迁移.NET Core的问题记录

这几天试着把目前的开发框架迁移到新的.net core平台,中间遇到的问题在这里简单记录一下。

迁移过程遇到的最大的问题IOC容器。我目前使用的IOC容器Castle Windsor还没有.net core版本的实现,虽然core本身提供有注入功能,但我想在代码上尽量保持与.NET Framework的兼容,最后还是选择使用第三方容器Autofac,不过在容器上层做了隔离,也就是可以随时替换掉IOC。
关于第三方容器接管.net core的注入实现,官方文档有介绍,也可以参考autofac的实现
https://github.com/autofac/Autofac.Extensions.DependencyInjection

第二个问题是.net core没有App Domain,不能像以前那样方便的加载项目程序集,替换方法是手工扫描BIN目录,再通过AssemblyLoadContext加载到内存。不过遇到一个问题是在加载入口项目DLL的时候,会提示无法加载,目前我是通过Assembly.GetEntryAssembly()后简单粗暴的排除掉。哪位朋友知道有更好的方法,劳烦告知一下。

其他方式:
var assemblies = DependencyContext.Default.RuntimeLibraries;//需要引用程序集

第三个问题是很多Type的反射接口不存在了,可以通过Type.GetTypeInfo()获取,不过要额外引用扩展库。

第四个问题是在发布到服务器IIS之后,出现下面的异常:

HTTP Error 502.5 - Process Failure

Common causes of this issue:
The application process failed to start.
The application process started but then stopped.
The application process started but failed to listen on the configured port.

WINDOWS系统日志:

Failed to start process with commandline '"dotnet" .\Portal.dll', ErrorCode = '0x80070002'.

首先说一下,在部署IIS的时候,需要在windows server上安装文件DotNetCore.1.0.1-WindowsHosting.exe,它会在IIS上添加一个aspnetcore module,托管net core的运行。新建站点后将应用程序池修改为无托管模式即可。就在这个地方我遇到上边的错误,页面一直提示502无法打开,端口和编译平台都没有问题。
网上找了很多方法试过后都没有效果,最后感觉还是hosting的问题,而且我在安排hosting文件的时候的确报过一次错,后来是用右键管理员运行安装完成的,然后到iis模块下果真没有找到aspnetcore module。
卸载后重装又出现了第一次的问题,安装失败。最后在stackoverflow上看到一句话

Make sure when you install the DotNetCore WindowsHosting you have access to the internet because the installer download the VS 2015 resist x64 as dependency.

VS 2015 resist x64 - http://download.microsoft.com/download/8/c/b/8cb4af84-165e-4b36-978d-e867e07fc707/vc_redist.x64.exe

果断下载安装后再运行WindowsHosting就没再报错了,这里还需要重启一下服务器。

https://aka.ms/dotnetcore_windowshosting_1_1_0

手指在键盘上飞快的敲下那一串域名,点击Enter,那一刻的感觉好极了@@

作者出处Ronli (Http://Ronli.cnblogs.com/)

转载声明:自由转载,谢绝演绎。请保留署名、链接及更新时间

更新链接:文章内容受撰文时个人水平局限,可能存在的错误及不准确之处谢谢指正;

请保留文章链接和更新时间,方便最终读者甄别。